¿Se puede justificar el uso de cuentas de usuario compartidas y genéricas para segregar y reducir el riesgo?

Usted tiene razón, el solo hecho de otorgar permisos a cada usuario que los necesita solo ocasionalmente no es una buena opción. Compartir cuentas privilegiadas no es una opción también.

Como no ha especificado su entorno, le proporcionaré dos respuestas:

Linux/*nix

Podría darle a cada administrador la opción de escalar a un nivel de privilegio más alto en su cuenta operativa. Por lo general, en Linux, lo hace utilizando sudo para ejecutar comandos privilegiados. Usted le otorga dicho permiso a un usuario al agregarlo al grupo / archivo de sudoers (Ejemplo: enlace ).

ElvalorpredeterminadoenlamayoríadelossistemasLinuxessolicitarnuevamentelacontraseñadelusuarioparapermitirleejecutarcomandosadministrativosutilizandosudo.Sinembargo,esposiblequedeseesolicitarunacontraseñadecuentaderoot(noeslamejoropciónyaqueesunacontraseñacompartida,peropuedeestarbiensialmenosnopermiteeliniciodesesióndirectodelaraíz,asegurándosedequesolosepuedausarsilatiene).Tambiénunacuentaoperativaconprivilegiodesudo).

Perosideseaunamejorprotección,puedesolicitarunacontraseñadiferenteporusuario,comosedescribeen enlace .

Por lo tanto, al usar sudo, cada usuario deberá conocer su propia contraseña para iniciar sesión (como operador), y también confirmar la contraseña para pasar a un modo administrativo cuando sea necesario. Si desea agregar protección adicional, incluso puede solicitar una segunda contraseña para acceder a privilegios administrativos (root o segunda contraseña por usuario). Pero cada usuario tendrá su propio usuario (y solo uno) y usted tendrá una buena trazabilidad.

Windows

Debería darle a cada administrador una cuenta administrativa y configurar UAC para que requiera que el usuario ingrese la contraseña nuevamente cuando ejecute las operaciones administrativas. Eso sería el equivalente de Linux con sudo. Sin embargo, no puede configurar una contraseña diferente para que se le solicite, por lo que usar dos cuentas para cada administrador parece ser la única opción si desea aislar realmente las cuentas operativas y administrativas. Eche un vistazo a esta guía de Microsoft, donde recomiendan exactamente eso: enlace

  

Separación de cuentas administrativas y de usuario para usuarios administrativos   Para cada usuario que cumpla una función de administrador de servicios, cree dos   cuentas: una cuenta de usuario regular que se utilizará para tareas normales y   administración de datos, y una cuenta administrativa de servicio para ser utilizada   Solo para realizar tareas de administración de servicios. El servicio   La cuenta de administración no debe ser habilitada para correo o usada para correr   aplicaciones que se utilizan todos los días, como Microsoft Office, o para   navegando en Internet. Siempre da las dos cuentas diferentes.   contraseñas Estas precauciones reducen la exposición de las cuentas a   El mundo exterior, y reducen la cantidad de tiempo que   las cuentas administrativas se registran en el sistema.

Podría crear un inicio de sesión que cree una sesión con un determinado usuario, que luego obtiene algún tipo de cookie de seguimiento o cosa, es decir. Con esto, aún podría rastrear al usuario y sus acciones.

Usualmente haces esto usando un marco como Play! o la primavera. Ejemplos para jugar! se puede encontrar aquí y aquí . El proceso es similar en diferentes marcos: el usuario inicia sesión: se valida, obtiene algún tipo de ID rastreable. Luego, puede crear un archivo de registro que haga un seguimiento de las acciones de los usuarios, o simplemente verifique a través de la ID, si un usuario tiene permiso para realizar una tarea específica.

Una palabra sobre los diferentes roles:

Los roles están ahí por una razón. Mantener los roles separados y solo por su deber específico ayuda a reducir los problemas con la capacidad de seguimiento y la seguridad. Un usuario solo debe tener los derechos para un determinado trabajo. Esto también se conoce como POLP - Principio de privilegio mínimo .

Si todos sus usuarios tienen privilegios de administrador Y operador, es difícil lograr el seguimiento de las acciones y la seguridad de los usuarios.

Un ejemplo simple podría ser un compañero de trabajo malintencionado, simplemente elimina o modifica datos importantes y luego borra todos los archivos de registro que podrían revelar su identidad. Como tiene todos los derechos que necesita, esto es muy fácil de hacer. Tener usuarios "normales" y "administradores" crearía una barrera, si el usuario no es un administrador, es posible que le falten los derechos para eliminar los archivos de registro, por lo que aún podría eliminar los datos, pero ahora el administrador puede rastrearlo.

¿Quizás sería útil implementar más roles / grupos que contengan SOLAMENTE los derechos que necesitan para realizar un determinado trabajo?

En este caso, depende de lo que quieras lograr.

La idea detrás de la segreación, por ejemplo, no se ejecuta como root, sino como un usuario limitado para las actividades diarias, es que si la cuenta se ve comprometida por algún motivo, el daño se encuentra en los derechos que tiene la cuenta del usuario limitado. La segreación NO protege contra usuarios maliciosos, de la misma manera que sudo no protege contra administradores malintencionados. Si un usuario malintencionado con demasiados derechos quiere hacer algo malicioso, ese usuario simplemente cambia a la cuenta requerida para sus tareas.

La protección contra la segregación está diseñada contra: Un ejemplo es si el usuario accidentalmente deja un terminal conectado y un usuario no autorizado toma el control del terminal, o si se instala un software malicioso o un virus en el terminal debido a una navegación web descuidada, entonces el virus o usuario no autorizado solo puede hacer lo que sea necesario. La cuenta de usuario limitada puede hacer.

Basándome en lo que describió, interpreto que operador es solo más de "usuario global", por ejemplo, el "usuario" normal solo puede iniciar sesión en su propio terminal, pero "operador" puede iniciar sesión en cualquier terminal como "usuario". / p>

En ese caso, recomendaría asignar el operador directamente al usuario, y luego usar algún tipo de escalamiento de privilegios en caso de que se requiera una cuenta de administrador, por ejemplo, "sudo" o algo similar.

Si desea tener tanto trazabilidad como segregación, recomendaría crear 2 cuentas de usuario para cada usuario. Uno con los derechos normales, y uno con los derechos aumentados. No veo ningún riesgo en combinar las cuentas de operador y administrador en una sola cuenta, para aquellos usuarios que tienen acceso de operador y administrador, ya que estas cuentas solo deben usarse para tareas de limpieza de todos modos, no para uso diario.

En realidad, en estos casos, incluso podría ser mejor dejar que las cuentas del operador / administrador sean cuentas individuales y tener una cuenta de usuario compartida / de grupo, como "Usuario". Dado que las cuentas de usuario no tienen ningún derecho especial, no importa si alguien las compromete.

Creo que hay múltiples opciones para diferentes propósitos:

1. ¿Desea evitar que sus usuarios utilicen la misma contraseña para el trabajo diario y para las tareas administrativas (para limitar las amenazas de seguridad si se roba la contraseña que se usa comúnmente)?
2. ¿Desea limitar los "usuarios avanzados" en algunos sistemas mientras los habilita en otros?
3. ¿Desea realizar un seguimiento (auditar) de sus usuarios mejor?

En términos generales, creo que hacer que todas las operaciones realizadas por un usuario sean rastreadas y administradas en una cuenta única tiene muchas ventajas, tanto para simplificar (menos complejidad significa generalmente menos fallas), tener una administración consistente como para rastrear y relacionar actividades.

Es decir, para el punto 3, definitivamente eliminaría los usuarios compartidos.

Para los puntos 1 y 2, tener varias cuentas para cada usuario es una opción, pero no es óptimo para el punto 3 y para la administración y simplificación mencionadas anteriormente.

De todos modos, como dijo CristianTM, en Microsoft es la mejor práctica: enlace
En Linux, es posible que desee tener una contraseña diferente, la raíz, que se solicitará para actividades privilegiadas (y podría tener la contraseña de root centralizada), pero no servirá para el punto 2 por sí solo (es posible que defina qué sistemas que un usuario puede sudo y qué no).

Sin embargo, el mejor diseño que puedo pensar se basa en los conceptos de los anfitriones de bastión y los servidores proxy de autenticación; Básicamente, la idea sería crear diferentes bastiones para acceder a diferentes servicios privilegiados. Bastion es muy frecuente que se autentique con contraseñas independientes a través de OTP (mucho más seguro que contraseñas), y los servicios detrás de ellos también pueden ser separados de una red prospectiva .
Al dar acceso para algunos usuarios a un bastión / proxy (probablemente 2 hosts al menos para redundancia) configurado para acceder a un servicio específico que autentique a los usuarios a través de OTP, podría lograr los 3 puntos anteriores en gran medida (con un registro / auditoría dedicado en estos servidores). También en Windows, podría definir que la autenticación para los usuarios en hosts de bastión a través de RDP se realice con OTP y no con la contraseña habitual.

Eliminar las cuentas de usuario compartidas lo antes posible.

La única vez que se necesita una cuenta de usuario compartida, es cuando varias personas necesitan acceder a un sistema arcaico que solo admite uno (o quizás solo algunos) usuarios.

Las únicas funciones que vale la pena desarrollar son las funciones de usuario y administración (y quizás varias funciones de administración).

Es probable que el rol del usuario sea muy limitado, bueno para iniciar sesión en las estaciones de trabajo, realizar tareas de trabajo y qué no. Debe averiguar qué es lo mínimo para la población general de usuarios y crear ese rol.

El rol de operador, no está seguro de para qué se usa exactamente, se utiliza para iniciar sesión en varios sistemas para realizar varias "operaciones" diferentes según su descripción. ¿Todos los operadores se conectan a todos estos sistemas? ¿Algunos de ellos se conectan solo con unos pocos mientras que otros se conectan con otros pocos y algunos se conectan con todos? Si existe una variación en quién se conecta con qué, elimine el rol y autorice a los usuarios caso por caso (Principio de privilegio mínimo) para evitar que los usuarios obtengan acceso innecesario o no autorizado a los sistemas y recursos. Esto mejorará su seguridad.

La cuenta de administrador se debe dividir en algunos grupos / roles específicos de los sistemas (o grupos de sistemas) que deben administrarse. También deben centrarse principalmente en tareas administrativas solamente. Si se encuentra en un entorno Windows AD, deshabilitar el inicio de sesión remoto obligará a los usuarios a usar sus cuentas de usuario normales para conectarse a sistemas remotos (con permisos generados a partir de la información de la cuenta del "operador") y luego usar su cuenta de administrador (jsmith_a por ejemplo) para Elevación UAC. Los grupos administrativos solo deben otorgarse a esta _a cuenta, y solo los grupos / roles para los sistemas que el usuario está autorizado a administrar. Esto tiene el doble efecto de evitar que una cuenta de administrador comprometida se use para sistemas remotos a múltiples, y también evita que una sola cuenta de usuario comprometida realice cambios administrativos.

Esto sin duda creará un "rastro de papel" para sus "operadores y administradores" y aumentará el nivel de responsabilidad en su entorno. También considere caducar la contraseña de la cuenta del administrador (_a) con más frecuencia que la contraseña de la cuenta del usuario. Un largo historial de contraseñas y una antigüedad mínima de contraseñas de 1 a 3 días deberían ser suficientes para evitar que los rotadores de contraseñas más dedicados pasen por alto sus contraseñas;) (no es que eso no aparezca en los registros de todos modos ...)

El sombrero es un buen lugar para comenzar.