¿Cuál es la mejor manera práctica de proteger a nuestros administradores de TI?

Estoy de acuerdo con y me gustaría ampliar la respuesta de Odo. Sé que para nuestra organización, la idea de un PAW dedicado fue excelente, pero no fue posible implementar uno basado en las pautas reales de STIG. Especialmente para las PYMES, tener una VLAN de acceso dedicado con esa máquina con solo cuentas de administración específicas es un poco más de lo que la mayoría puede manejar. Terminamos implementando un entorno similar a lo que sugería odo. Tenemos varios administradores que realizan diversas tareas en múltiples sitios, por lo que el vector de amenazas para que alguien obtenga acceso de administrador a nuestros centros de distribución fue significativo. Aunque creo que si realmente consideras tus roles, solo hay unos pocos administradores que realmente requieren permisos de administrador de dominio completos en tus DC. Terminamos creando (a falta de una palabra mejor) un grupo de administradores de elevación que nuestros administradores de TI de todos los días usaban en las estaciones de trabajo diarias. Estas cuentas no tienen privilegios administrativos en los servidores y, en realidad, se les han denegado los privilegios de inicio de sesión a través de los GPO. Debido a las restricciones en nuestro entorno, no podemos utilizar ningún dispositivo móvil en nuestro edificio y no tenemos el presupuesto para los tokens, por lo que MFA no era realmente una opción. Terminamos usando los GPO de Servicio de Terminal (aunque creo que ahora se llaman RDS) para permitir o denegar el acceso remoto a las cuentas según su nivel de privilegio. Por ejemplo, los administradores de elevate no pueden iniciar sesión de forma remota en ninguna estación de trabajo, y los administradores de dominio no pueden iniciar sesión de forma remota en ningún servidor (también se debe mencionar que a los miembros de DA / EA también se les deniega el inicio de sesión en las estaciones de trabajo diarias). Esto ayuda significativamente a evitar que un atacante robe credenciales que se utilizan a diario y causan estragos en su sistema. Existen varias guías muy útiles sobre esto de diferentes fuentes, generalmente (usamos) plantillas STIG para crear nuestra línea de base. Algunos puntos importantes que deben tenerse en cuenta en cuanto a los elementos anteriores son Denegar inicio de sesión para cuentas de dominio altamente privilegiadas ( V-63877 ) y denegar el inicio de sesión a través de RDS para cuentas de dominio altamente privilegiadas ( V-63879 ). Sus administradores tendrían que elevarse en un indicador de UAC usando sus cuentas privilegiadas, pero garantiza que si su computadora portátil o su estación de trabajo se rompen, el atacante necesitará múltiples conjuntos de credenciales que realmente logren cualquier cosa.

El uso de un VDI / Jump Server no es una idea tan terrible, es una técnica bastante común: si la configura con algún tipo de autenticación multifactor (que no está en la computadora portátil), por lo menos está comprometida. la computadora portátil no puede simplemente conectarse a su red de administración.

Separaría las cuentas operativas menos privilegiadas de los administradores (para las tareas diarias) de las cuentas más privilegiadas, como dominio / db admin (que se usan durante los cambios en la arquitectura del dominio / base de datos, una tarea mucho más rara).

Sí, podría requerir ajustes finos, funciones personalizadas, etc., pero durante el proceso comprenderás mejor el panorama relacionado con RBAC.

Para la mayoría de las cuentas con privilegios, recomendaría contraseñas compartidas (es decir, la mitad de la contraseña almacenada en warbox) combinada con 2FA.