Acabo de comenzar mi pasantía en una organización gubernamental y mi primera tarea es desarrollar un sistema de usuario para nuestra granja de servidores interna de más de 120 servidores Redhat y Windows. La granja de servidores interna se gestiona con Puppet. Tal como están las cosas ahora, todos inician sesión con la misma cuenta raíz/administrador, lo que debería explicar por sí solo por qué es un gran problema por varias razones. No tengo los números exactos, pero estamos hablando de al menos 30 personas usando la misma cuenta, y gran parte de su trabajo no requiere ese nivel de acceso/privilegios. He propuesto dos soluciones para el problema y realmente agradecería algunos comentarios de ustedes.
1) Autenticación a través de AD a la granja de servidores
La idea es configurar un servidor de autenticación (preferiblemente dos para mayor redundancia), que esté conectado al AD gubernamental mediante SSSD/FreeIPA, y si los usuarios están autenticados, se les concede acceso a la granja de servidores, donde se utiliza Puppet para administrar sus privilegios. . Administrar privilegios a través del AD no es una opción, porque esta organización es administrada por una instancia superior que controla el AD. Mi gerente y yo preferimos esta solución porque podemos dejar que la otra administración administre las cuentas y, por lo tanto, no tener dos sistemas separados. Existe el requisito de proporcionar informes mensuales sobre la actividad de los usuarios si una organización gubernamental tiene un sistema de usuario separado del AD principal, y mi departamento está muy ocupado, por lo que nos gustaría evitar una tarea como esa.
2) Administración local de privilegios de usuario.
La otra solución es eliminar el servidor de autenticación y simplemente administrar el sistema del usuario y sus privilegios a través de Puppet. De esa manera tenemos el control total y no tenemos que depender de la administración. La desventaja de esto es que tendríamos un sistema de usuario independiente, que hay que gestionar. Por supuesto, esto puede suponer una amenaza para la seguridad si los antiguos empleados/consultores no se eliminan del sistema, pero lo más importante es que no tenemos tiempo para otra tarea que requiere mucho tiempo.
Después de leer artículos y otras publicaciones sobre este tema, entendí que SSSD/FreeIPA es probablemente el camino a seguir, pero no estoy seguro. Entonces, ¿qué piensan ustedes? ¿Cuál de las soluciones propuestas es la mejor y/o existe una tercera y mejor solución al problema?
¡Gracias de antemano!
Respuesta1
Respuesta de alguien que trabaja en un laboratorio del gobierno de EE. UU. Une tus sistemas al dominio AD. realmLas herramientas funcionan bien con Red Hat 7. Configure sssd para la autenticación de usuarios. Utilice Puppet para administrar /etc/security/access.conf para controlar el acceso de los usuarios y Puppet también controla /etc/sudoers y /etc/sudoers.d. Básicamente, use su opción 1. Además, configure syslog para enviar todos los registros de seguridad a un servidor de registro central con acceso limitado. Ahora tienes cuentas controladas por el AD principal, por lo que tendrás un dolor de cabeza menos. Todos los inicios de sesión y solicitudes de sudo se registran en el servidor syslog central para que tenga un lugar al que acudir para obtener informes de uso. También bloquearía la cuenta raíz para que no se pueda iniciar sesión a través de ssh y obligar a las personas a usar su o sudo. Haga que el gerente desaconseje su como opción de rutina.
Buena suerte con tu pasantía. Este es un gran proyecto para implementar.