¿Se deben BORRAR / eliminar las cuentas de administrador inactivas?

Argumentaré para eliminarlos. Lo único que impide que se utilicen estas cuentas es:

  

Los administradores inactivos no pueden iniciar sesión.

Y esa es una defensa contra la fuerza bruta (o el engaño) de una autenticación, pero no la defiende contra la escalada de privilegios.

Las directrices de OWASP para aplicaciones web argumentan que un cliente nunca debe mantener una sesión con autenticación para dos cuentas separadas. Eso evitaría la escalada de privilegios en la mayoría de los casos. Sin embargo, de lejos, no todas las aplicaciones web siguen las pautas de OWASP.

Por lo tanto, mantener esas cuentas inactivas pero aún privilegiadas es una posibilidad de un vector de ataque.

El otro lado de la moneda es que el procedimiento para eliminar las cuentas puede consumir recursos o, incluso, ser inseguro en sí mismo. Pero la gestión para producir un procedimiento de eliminación de cuenta que sea vulnerable a un ataque es mucho menos probable que ser golpeado por una escalada de privilegios.

Simplemente no realice el procedimiento de eliminación periódica de la cuenta para eliminar las cuentas inactivas al iniciar sesión en una cuenta de administrador activa a través de la red.

En el momento en que me encuentro con una pregunta como esta, siempre estoy obligado a decir "Sí, elimine las cuentas inactivas". ¿Por qué? Porque es una "buena práctica" eliminar cuentas antiguas que ya no están en uso. Algunos casos de uso que se aplican al límite en este escenario:

• Reutilización del nombre de usuario: si los nombres de usuario son "gclooney" en lugar de "admin22", tiene menos colisiones al crear nombres de usuario si un nuevo administrador resuelve el mismo nombre de usuario / identificador
• Desperdicio de recursos: estoy de acuerdo en que ya no estamos ejecutando una aplicación en una Raspberry Pi. Pero aún así, es un desperdicio de memoria y también un control adicional. No solo ahora comprueba si el nombre de usuario es correcto, sino que también necesitaría un control adicional para su validez.
• Enumeración innecesaria: al suponer que una fuga de datos / inyección de SQL conduce a la filtración de la información del usuario (administrador), ahora corre el riesgo de filtrar más información de la necesaria, por ejemplo, también tiene los nombres y apellidos del ex administrador almacenados en un registro DB relacionado.
• punto de Grochmal sobre las pautas de OWASP.

Siempre errar en el lado más seguro y asumir que el malo puede convertir las cosas más extrañas en su ventaja!

  

¿Es más beneficioso o menos?

La pregunta es: "¿Qué razones podría haber para NO eliminarlas?" ¿Qué podría ser menos beneficioso al respecto? Hay muchas más razones (como los otros carteles han mencionado), para eliminarlas y luego no.

Eliminando: < 30 minutos

eliminando: > muchos días de recuperación de desastres

Editar

En respuesta a Kzqai

Si su base de datos está configurada correctamente, debería tener a sus usuarios en su propia tabla. Así que su historial espero que sea parte de una tabla diferente. Y si no, le sugiero que vuelva a evaluar la configuración de su base de datos. Además, si sigue las buenas prácticas, debería tener copias de seguridad de su base de datos a las que podría hacer referencia en el caso de mirar hacia atrás a los usuarios antiguos / eliminados. Pero de manera realista, si la base de datos está bien configurada, podría eliminar un usuario, sin afectar los efectos de cualquier otra cosa relacionada con ese usuario.