it-swarm-es.com

¿Es común permitir el acceso y los derechos de administrador de escritorio local y / o Active Directory para los desarrolladores en las organizaciones?

Trabajo en una empresa con un personal de aproximadamente 1000+. Actualmente contamos con personal de desarrollo de programación que trabaja en proyectos basados ​​en la web (aproximadamente 50 personas).

Recientemente, debido a preocupaciones de seguridad, nuestro departamento de TI y Seguridad implementó una restricción que ya no permite el acceso de administrador local en las máquinas. Toda la compañía ejecuta el sistema operativo Windows para estaciones de trabajo y servidores. Estuve completamente de acuerdo con la decisión de eliminar al administrador, honestamente, pensé que era mucho tiempo atrasado (ya que la compañía maneja los datos del paciente y requiere el cumplimiento de HIPAA). Lamentablemente creo que tomaron la decisión demasiado lejos. Supuse que se crearía un subgrupo o grupo de AD para usuarios que legítimamente necesitaban acceso de administrador para hacer su trabajo (EX mi equipo de programación) algo así como un grupo de tecnología que retendría el acceso de administrador. Sin embargo, este no fue el caso, el único grupo creó un grupo de administración específico para el personal de la red y de la mesa de ayuda.

El principal problema es que, como desarrolladores web, ejecutamos programas que requieren acceso de administrador local y desafortunadamente no podemos hacer nuestro trabajo sin que se ejecuten como administradores. Los programas de ejemplo incluyen Visual Studio para desarrollo web ASP.NET, MAMP para desarrollo local, compositor, etc. Creo que la razón principal por la que estos programas necesitan acceso de administrador es porque necesitan ejecutar y modificar IIS local, línea de comando, etc.

Básicamente hubo una breve notificación de cuándo se eliminó el acceso de administrador local. Después de aproximadamente 2 días de que el equipo de desarrollo estuvo muerto en el agua en términos de poder trabajar y yo y otros líderes de equipo básicamente gritamos y gritamos al personal de TI para encontrar una solución que finalmente aceptaron y encontraron un programa de terceros que funciona como un paso que permite a los administradores crear la capacidad de que ciertos programas se ejecuten como administradores aunque no tengamos acceso de administrador local.

Desafortunadamente, este programa que utilizamos para acceso de administrador local es increíblemente defectuoso y poco confiable, y no proviene de una fuente confiable y no parece haber muchas alternativas disponibles. (Preferiría no divulgar el programa que utilizamos).

Mi pregunta es, ¿es típico no permitir el acceso de administrador local a programadores/desarrolladores en una empresa o corporación? Y si es una práctica común hacerlo, ¿cómo ejecutan los desarrolladores los programas que necesitan como administrador local?

Un poco más de información sobre nuestro entorno de red (no es que realmente se relacione con la pregunta que pensé agregar):

  1. Usamos AppBlocker para bloquear programas que no están en una lista aprobada
  2. Utilizamos un bloqueador de seguridad de correo electrónico que hace cosas como escanear y convertir archivos adjuntos a PDF, etc.
  3. Tenemos al menos 2 programas antivirus importantes en todas las estaciones de trabajo.
  4. La red y sus servidores están muy segregados, los usuarios solo tienen acceso a ciertos servidores, carpetas y bases de datos a los que legítimamente necesitan acceso.
123
TroySteven

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 físicamente separados y sin aire, pasan 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 enviar correos electrónicos, etc. Todos los usuarios están estrictamente bloqueados, y existe un estricto control 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 conflictivos de alta seguridad y libertad de desarrollo, esta es una solución común.

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

114
Joe

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 la última situación, generalmente se hacen algunos ajustes para que puedan realizar su trabajo sin demasiada fricción.

Una acomodación muy común es el acceso a un hipervisor en la estación de trabajo (ya sea alguna versión de VMWare o Hyper-V que viene con Windows), junto con el 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 tienen derechos de administrador para el sistema operativo invitado. Por lo general, algunas de estas máquinas virtuales tendrán una larga vida, incluso si no se ejecutan todo el tiempo, donde rara vez se trata de la necesidad de preparar un VM desde cero solo para hacer lo que debería) ser una prueba rápida de algo que necesita privilegios de administrador.

El hipervisor puede o no estar configurado para permitir el acceso a Internet para sus máquinas virtuales; Lo he visto en ambos sentidos, aunque personalmente estoy firmemente 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, como mínimo, configurarse para forzar a las máquinas virtuales a un vlan dedicado, separado del resto de la red corporativa. No estoy seguro de que esto sea posible aplicarlo 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 máquinas virtuales devloper. Luego, puede dar un pequeño tutorial a los desarrolladores sobre cómo configurar una etiqueta vlan en un VM y hacerles saber qué etiquetas vlan se permitirán en su puerto de conmutador. También he visto esto forzado a través de la capacitación simplemente como un edicto de políticas, en lugar de a través de medidas técnicas, con una auditoría amigable ocasional para alentar el cumplimiento y asegurarse de que los desarrolladores sepan que es importante.

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

70
Joel Coehoorn

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

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 administrador local.

47
Justin

En mi experiencia, permitir y no permitir el acceso de administrador local es común, tan común como soluciones sucias para este último. - Entonces debes preguntarte a ti mismo:

¿Qué amenaza a su red empeora con los derechos de administrador local?

Para lo cual la respuesta debe ser: NONE - El acceso a los recursos en su red debe estar restringido por usuario, sin relación alguna con el hecho de que este usuario tiene acceso local root, admin o masterOfTheUniverse 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.

Debe confiar en sus desarrolladores para que manejen 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 a un administrador local es que un desarrollador rompa su propia máquina (que ya puede hacer con una taza de café).

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

Por qué los desarrolladores deberían tener derechos de administrador local

Sus desarrolladores son personas a las que les confía el diseño de las operaciones centrales de su negocio. La mayoría de las empresas actuales 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 está el beneficio de una mayor productividad, porque el desarrollador puede simplemente configurar, instalar y probar todo lo que necesita en su máquina local. Es posible que necesite cierto software, herramientas auxiliares o configuraciones inusuales para experimentar con ciertos aspectos de su software (por ejemplo, ejecute su software en una versión anterior de un sistema operativo o con controladores/SDK anteriores).

En segundo lugar, está el beneficio (en mi opinión, aún mayor) de mostrar a sus desarrolladores cómo los valora. Usted les muestra que confía en ellos con su propia máquina: trata a sus desarrolladores como personas responsables de TI que pueden administrar su propia máquina sin una niñera. (En muchas empresas donde los desarrolladores no obtienen el administrador local, tendrán que pedir 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 sénior , pero todavía tienen que rogar por cosas que simplemente necesitan para hacer su trabajo, lo que puede ser muy frustrante).

31
Falco

En mi carrera, con empresas bastante pequeñas (menos de 100 personas), siempre tuvimos derechos de administrador local. O tenemos máquinas de escritorio reales que son mantenidas por TI, pero obtuvimos los derechos, o se nos permitió tener máquinas virtuales de todo tipo que administramos completamente por nuestra cuenta.

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

30
Marcel

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 medio:

  • sysadmins tenía 2 cuentas, una (no administradora 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 no administrativa
  • los desarrolladores (y algunos suarios avanzados) recibieron una cuenta local con privilegios de administrador de máquina local. Se suponía que rara vez se usaba cuando se requería la administración local.

Negar 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 primaria o a una cuenta secundaria debe depender de la frecuencia de la operación del administrador:

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

Elige el tuyo si estás en el medio ...

28
Serge Ballesta

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

Parece que su organización está en el límite de pequeños y grandes, así que ...

Parece que es hora de que su organización desarrolle algunas 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 necesitan oponerse entre sí para su empresa. Puede evitar este choque por completo realizando sus actividades de desarrollo en una red que no tiene acceso a los recursos de su red comercial principal.

No estás haciendo desarrollo contra tus activos de producción de todos modos, ¿verdad?

Si es así, no debería serlo: presenta un riesgo significativo para sus activos, particularmente para su disponibilidad.

Una práctica mucho mejor es tener una configuración completa del entorno de desarrollo que reproduzca porciones clave de la funcionalidad y los conjuntos de datos (sin exponer algo como información privada sobre individuos 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 (incluyendo 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 protegerse como la mayoría de las redes. No solo arroje todos sus activos de código y desarrollo en línea sin pensar en el control de acceso o las medidas de seguridad básicas.

También he visto algunos lugares dar un paso más allá y escribir todo su código en un entorno y luego construirlo/implementarlo en otro entorno completamente separado para las pruebas de integración.

13
John-M

En primer lugar, debe aprender que no importa qué es "común" o "típico" porque: normalmente, estas situaciones se manejan horriblemente. Estás haciendo el mejor caso para esta declaración.

Si el acceso de administrador local es necesario para una persona (ya sea un contratista o un empleado), entonces es obligación del equipo/persona de seguridad, quien esté a cargo de esa área en particular, encontrar una solución . Existen múltiples soluciones: crear una VLAN aislada, máquinas virtuales y otras fueron nombradas aquí.

No tiene ningún sentido preguntar sobre 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/persona de seguridad planifica una solución segura que luego implementa el departamento de TI en esta organización particular .

Si la solución que se implementó no funciona correctamente y, por lo tanto, aún no puede trabajar, vuelva a hablar con el equipo/persona de seguridad. Si esto no funciona, comuníqueselo a su jefe o contratista.

Lo que estás haciendo ahora 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.

11
Tom K.

El problema que realmente tiene es que TI competente está intentando hacer cumplir una regla descabellada. Realmente solo tiene una opción, darles a los desarrolladores un acceso de administrador efectivo.

Sigo viendo que se repite el mismo consejo una y otra vez, que se reduce a una segunda máquina que el desarrollador tiene administrador pero no internet. Si desea 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 tienen solo una opción para buscar actualizaciones: Internet. No puede 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 partida; Es el premio gordo. No hay razón para buscar administrador desde allí. El infractor tiene la capacidad de modificar el código de barras para insertar puertas traseras. Obtener administrador en la caja del desarrollador no es mucho más interesante.

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

He escuchado muchas historias sobre la política de que los desarrolladores no obtienen administración, pero la práctica de TI mira hacia otro lado mientras los desarrolladores revocaron la política de seguridad. He escuchado que muchos más de TI nunca se enteran. Escuché que algunos de los gerentes del desarrollador les dicen a los desarrolladores que omitan los controles de seguridad.

Tarde o temprano, las organizaciones aprenden a dar solo a los desarrolladores admin. La mayoría de los que probablemente no terminan haciéndolo sin saberlo realmente.

Es mucho más prudente darles a los desarrolladores administrador local en una caja conectada a Internet y al dominio local y estar preparados para enfrentar las consecuencias. Proteger la producción en su lugar. Hay menos personas que deberían acceder a la producción con un alto nivel de privilegios, por lo tanto, el bloqueo es más fácil y las organizaciones competentes aprenden a hacerlo.

Pero eliminar de repente a un administrador como este casi siempre resulta en la pérdida de los desarrolladores más importantes. No quieres eso.

Como desea 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 desarrolladores administrador local. El fabricante de Windows ha concluido que no hay suficientes beneficios para no dar administrador de desarrolladores para que valga la pena. Por lo tanto, debes hacer lo mismo.

8
Joshua

He visto dos enfoques que funcionan.

  1. Brinde a los desarrolladores acceso de administrador a sus máquinas. Este es el enfoque más fácil y más común. Suele ser 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 generalmente estará formado por 3-4 personas. Descubrirá que los requisitos de hardware de los desarrolladores aumentan drásticamente, ya que usará contenedores y/o máquinas virtuales, por lo que debe presupuestar la compra de nuevo hardware para todos los desarrolladores. Cuando despliegue, comience con un equipo de primeros usuarios, luego mueva gradualmente a todos sus desarrolladores a una máquina sin acceso de administrador. Este proceso llevará al menos seis meses.

Si hace lo que hace su empresa ahora, sus desarrolladores lo soportarán durante un mes más o menos y luego comenzarán a buscar nuevos trabajos.

8
UEFI

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

En algunas organizaciones, es común dar 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 algunas organizaciones, todo el desarrollo debe llevarse a cabo en un entorno sin espacio de aire, en el que no se puedan ingresar ni sacar dispositivos electrónicos.

La mayoría de las organizaciones se ubican entre estos dos extremos. Cuanto más bloqueado esté el entorno de desarrollo, menos productivos serán sus desarrolladores y más probabilidades tendrá de perder su mejor talento. Su organización necesita 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.

8
James_pic

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

De vez en cuando organizaban un evento social, como jugar a los bolos. Unirse era gratuito, pero tenía que agregar su nombre a una lista en un archivo de Excel, ubicado en una carpeta compartida. Esa carpeta estaba dedicada a eventos sociales, nada más.

Entonces, ¿quieres jugar bolos? ¿Quieres agregar tu nombre a esa lista? Ohhhhhhhhhh, querido ... No es que puedan dejar que todos editen ese archivo, ¿verdad? Tiene que solicitar 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 completados
  • Busque y descargue el documento llamado "Hoja de lanzamiento"
  • Imprímelo
  • Rellene con su solicitud y firme
  • Entregárselo a la secretaria
  • La secretaria llevará todas estas solicitudes al gerente en la mañana del día siguiente.
  • Tarde o temprano el gerente lo firmará
  • La secretaria te lo devolverá
  • En este punto puedes escanearlo
  • Abra el sitio utilizado por la TI para gestionar tickets
  • Cree un ticket que describa (nuevamente) lo que necesita y adjunte la Hoja de lanzamiento escaneada. No olvide establecer la urgencia, de una hora a dos semanas.
  • Finalmente, la TI lo hará (con suerte)

En promedio, tomaría de 3 a 4 días hacerlo. En algunos casos, semanas. Realmente eficiente, ¿eh? Oye, ¿pediste acceso a cierta carpeta pero olvidaste mencionar la subcarpeta? ¡DECIR AH! ¡Has ganado otra ronda! ¿Y adivina qué? Como seguían algún proceso de control de calidad, organizaban documentos en ¡mucho de diferentes carpetas. Cuando llegó un nuevo colega, podría pasar fácilmente 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 departamento de informática le importa un comino la urgencia? Ciertamente no.

Entonces, ¿a qué condujo este enfoque? Que si quería robar todo lo que la compañía alguna vez hizo, solo tenía que traer una unidad USB y conectarla a su PC. ¿No tiene acceso a esa carpeta "Confidential_Documents"? Solo pídalo, 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" fue increíblemente lento, torpe y frustrante, y no protegió en absoluto sus propiedades, pero al menos nadie podía meterse fácilmente con los participantes en el evento de boliche ( obligatorio xkcd ).

Por favor, no seas esa compañía. Como han dicho otros: no preguntes si es común (lo es), solo pregunta si tiene sentido. Y la respuesta es: no, no lo hace, 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 regulares para proporcionar un soporte más rápido que a través del equipo de TI.

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

Personalmente, preferiría que los desarrolladores no tengan acceso de administrador local. Podríamos investigar las aplicaciones que necesitan UAC (averiguar las carpetas, las claves, etc. que necesita) y mitigar el mensaje UAC, pero eso lleva tiempo e investigación y no todas las empresas tienen los recursos para hacerlo. Entonces, los encontramos a mitad de camino y esperamos 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.

5
James

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 como máximo una vez al mes y, por lo general, mucho menos que eso.

Respuesta larga: Depende ...

Para la población general de usuarios, no necesita realizar un análisis de riesgo completo para comprender que el acceso de administrador tiene un gran potencial para 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 la "mejor práctica" y hacer un movimiento en blanco de talla única es una evasión típicamente causada por la (s) persona (s) responsable (s) de la seguridad de la información que carece del tiempo y/o conocimiento para ejecutar los números y obtener una decisión de tratamiento de riesgo basada en hechos.

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

En el momento en que estás, por lo que escribes, eso es un desconocido. Puede solicitar que se realice un análisis de riesgos adecuado, agregando su conocimiento experto al costo de mitigación de la ecuación, poniendo en números la productividad perdida 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 de profesión, por lo que me hacen estas preguntas de forma regular) es separar la red de desarrolladores de la red de la oficina ordinaria para contener el área de mayor riesgo. Fortalezca las máquinas de desarrollo lo suficiente e insista en los firewalls locales y la protección antivirus actualizada y estará bien contra los escenarios de ataque típicos. Si su empresa tiene alguna exposición externa, también puede agregar capacitación de conciencia adicional para los desarrolladores para que no sean víctimas de ataques dirigidos tan fácilmente.

Supervisé personalmente los entornos de desarrollador de ambos tipos, y con un poco de esfuerzo se puede hacer que ambos funcionen bien. Solo desconectar una forma de trabajo establecida lo estaba manejando mal y era de esperar la reacción de la que era parte. Pero lo hecho, hecho está, y probablemente sea inteligente no centrarse en eso y mirar hacia el futuro.

4
Tom

Resolvimos este problema usando un 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 forma, podemos separar el acceso a Internet y los datos importantes del uso de los derechos de administrador mientras obtenemos una forma de ejecutar los programas necesarios en un entorno cerrado.

4
Yannjoel

Estoy en el mismo barco que sus desarrolladores de software. Nuestra empresa recientemente pasó de estaciones de trabajo con acceso de administrador a máquinas virtuales sin. Estaba afectando tanto nuestro flujo de trabajo que muchas veces me encontré haciendo nada más que leer artículos para que el departamento de TI ejecutara algo como administrador para mí.

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

Una de nuestras máquinas virtuales era una máquina 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 era desconectada completamente de Internet. De esa manera, no pudimos descargar nada en esa máquina. (Aunque aún podríamos descargarlo desde el otro y copiar la descarga de nuevo ...) Todavía obtuvimos acceso a sitios internos e incluimos 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 necesitamos que cada máquina esté en su propio monitor, pero de todos modos usamos una pantalla para el código y la otra para la navegación web de todos modos.

4
Jimenemex

Separe sus redes

Debe tener entornos relativamente aislados para el desarrollo, las pruebas, la producción y los negocios. Esto permite a sus desarrolladores tener privilegios donde los necesitan.

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

¿Qué pasa dónde?

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/probar.

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

Pruebas

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

Las implementaciones deben reflejar lo que los administradores mantendrán en producción para 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 fines de prueba para evitar la liberación de accidentes).

Los desarrolladores a menudo necesitan registros del sistema y acceso de depuración, y estas son las únicas razones por las que deberían 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 debería 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 transmitido por Internet y cambios accidentales, las cuentas de las redes de desarrollo/prueba/negocios 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, redes y gestión de proyectos. Acércate lo más posible al ideal; Es realmente todo lo que podemos hacer.

Negocio

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, prueba y producción deben aislarse de estos riesgos en la mayor medida posible.

Detalles, Detalles, Detalles

Es posible que su organización se haya excedido. Es más fácil balancear el péndulo por completo que lidiar con la miríada de detalles esenciales para una arquitectura de red flexible y segura.

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. Existen reglas de firewall/ACL restrictivas entre entornos
  4. Se han implementado 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 recursos en Internet (si no quieren saltar de la red de negocios, lo cual es oneroso)
  • Cuenta de desarrollo privilegiada para configurar la estación de trabajo y el código de prueba
  • Cuenta de prueba privilegiada para depurar aplicaciones
  • Cuenta comercial no privilegiada para correo electrónico, web, intranet

Si tiene desarrolladores que realizan alguna validación o trabajo de control de calidad, también pueden necesitar cuentas sin privilegios en el entorno de prueba.

Los desarrolladores no deberían 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, debería establecerse un riguroso proceso de control de cambios.

3
DoubleD

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 el de Micosoft) todavía tienden a ignorar la idea de la separación de privilegios. Este tipo de control de acceso está poco 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 usan la separación de privilegios de manera adecuada tanto para usuarios reales como para servicios. Pero en cualquier plataforma, colocar barreras en la forma en que los implementadores separan los privilegios es aún más contraproducente para la seguridad que otorgarles privilegios de administrador completos (locales) .

Por otro lado, aunque sé poco sobre el desarrollo en MS-Windows, me parece sorprendente que se requiera el 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 esta facilidad a los usuarios designados sin darles locales administración. Uno de los grandes cambios en IIS7 fue la capacidad administrador delegado . Y siempre ha sido fácil delegar la reconfiguración de Apache, MySQL y PHP.

hubo una breve notificación de cuándo se eliminó el acceso de administrador local

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

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

Ese es un enfoque muy ingenuo para proteger la integridad de estos sistemas y pinta una imagen de lo que tiene que enfrentar.

no parece haber muchas alternativas por ahí

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

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

2
symcbean

Es típico que se deniegue el acceso de administrador local a los desarrolladores en empresas donde los desarrolladores son tan inútiles/maliciosos que abusan de esos privilegios, o donde el departamento de "TI y Seguridad" está dirigido por idiotas sin idea que ven a todos no su círculo interno como una obvia amenaza de seguridad para 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í.

2
Ian Kemp