¿Dónde debemos mantener los nombres de usuario y las contraseñas externas (subcontratistas)?

3

Tenemos tres entornos:

  • Pruebas y desarrollo
  • Preproducción
  • Producción

En nuestra empresa, todos los técnicos, incluidos los administradores de sistemas y los administradores de red, son subcontratistas, por lo que muchos de ellos (pero no todos) necesitan acceso a casi todo.

¿Dónde debemos mantener las credenciales externas (subcontratistas)?

Hoy tenemos dominios diferentes para ellos, un dominio diferente para cada entorno: "EXTERNALSTEST", "EXTERNALSPRE" y "EXTERNALSPRO" (también tenemos dominios para nuestros propios empleados ("COMPANYTEST", "COMPANYPRE" y "COMPANYPRO ").

También asignamos diferentes nombres de usuario a los externos en función del entorno: test_username para entornos de "Pruebas y desarrollo" y "Preproducción" y nombre de usuario para entornos de "Producción".

Estamos buscando hacer esto más fácil pero seguro.

¿Podemos tener un nombre de usuario único y un dominio único "EXTERNALS" almacenados en "Producción" para todos los empleados externos?

El riesgo que veo aquí es que si tenemos el dominio EXTERNO solo en Producción, tendremos que abrir la comunicación de los otros entornos a Producción y hoy tenemos una buena separación de estos entornos con reglas de cortafuegos.

¿Es esta la mejor organización de usuarios externos? ¿Es esto seguro?

    
pregunta Eloy Roldán Paredes 11.11.2016 - 10:50
fuente

1 respuesta

2

No soy un arquitecto de redes, sino un teamer rojo. Las redes que han sido las más difíciles desde la perspectiva de la administración de contraseñas y la segregación han sido las de los administradores que necesitan una cuenta de usuario y una cuenta de administrador. Por lo tanto, si son externos, usarán su cuenta de usuario con autenticación de dos factores para acceder a la VPN para el entorno que necesitan. Después de acceder a la VPN a través de la autenticación de dos factores, tendrían que acceder a la bóveda de contraseñas para "verificar" sus credenciales administrativas. Lieberman parece ser una opción decente. También requeriría una autenticación de dos factores para la bóveda de contraseñas con un token blando / duro diferente. Después de que los administradores revisen su contraseña y luego terminen con ellos, haga que cambien las contraseñas, sé que Lieberman hace esto errrr lol. Esto AYUDARÁ a mitigar la posibilidad de que las credenciales se obtengan de la memoria, caché, secretos, etc.

Creo que la segregación de los dominios es buena, asegúrese de verificar la relación de confianza entre ellos. Los diferentes dominios no deben tener confianzas establecidas (independientemente de lo que digan los demás), de lo contrario, ¿cuál es el punto de un dominio diferente? Aquí hay un enlace al sitio web de Lieberman que brinda una descripción detallada de cómo intentan mitigar los ataques a las credenciales: enlace

En cuanto a la opción de usar LDAP y Kerberos en Internet ... por favor ... no hagas eso ... No tengo suficientes puntos para responder directamente al comentario. Leí la documentación que se proporcionó: en primer lugar, no parece ofrecer la posibilidad de usar la autenticación de 2 factores, lo que es horrible en sí mismo, pero más aún cuando solicita una solución utilizada principalmente por los administradores. Además, solo busqué y ofrece la consola administrativa para la administración de usuarios y autenticación en Internet, con un nombre de usuario y contraseña de administrador simples. Esto lo dejaría susceptible a la fuerza bruta durante todo el día ... las llaves del reino. Algunos pueden decir que no tiene que ponerlos en Internet, sin embargo, parece que la mayoría de los servidores "MarkLogic" son de una simple búsqueda de shodan. Se ve incompleto en el mejor de los casos.

Puedo decir por experiencia que la autenticación de 2 factores crea un enorme dolor de cabeza y molestias para los hackers durante sus operaciones. Especialmente cuando se combina con una buena gestión de contraseñas de las credenciales administrativas, es decir, las credenciales cambian con frecuencia, son diferentes de las credenciales del usuario, y se requiere otra barrera de autenticación de 2 factores para acceder a ellas.

TAMBIÉN !!!!! No permita que el token de software sea solicitado y aprobado automáticamente por el usuario que lo está solicitando, también conocido como un portal de autoservicio para tokens de software. Eso debe ser un proceso de validación manual. No creo que esta sea una solución completa, sin embargo es un buen comienzo. Espero que esta perspectiva ayude en todo caso.

    
respondido por el Beetle 26.11.2016 - 00:50
fuente

Lea otras preguntas en las etiquetas