Gli account di amministratore inattivi devono essere CANCELLATI / cancellati?

Discuterò di eliminarli. L'unica cosa che impedisce l'utilizzo di questi account è:

Inactive administrators cannot log in.

E questa è una difesa contro il bruto forzare (o ingannare) un'autenticazione, eppure non difende dall'escalation dei privilegi.

Le linee guida OWASP per le applicazioni web sostengono che un client non dovrebbe mai tenere una sessione con autenticazione per due account separati. Ciò impedirebbe l'escalation dei privilegi nella maggior parte dei casi. Tuttavia, di gran lunga, non tutte le applicazioni Web seguono le linee guida OWASP.

Pertanto, mantenere gli account inattivi ma ancora privilegiati è una possibilità di un vettore di attacco.

L'altro lato della medaglia è che la procedura per cancellare i conti può consumare risorse o, addirittura, essere insicure di per sé. Ma riuscire a produrre un account eliminando una procedura vulnerabile a un attacco è molto meno probabile che essere colpito da un'escalation di privilegi.

Solo non effettua la procedura di eliminazione periodica dell'account per eliminare gli account inattivi effettuando il primo accesso a un account amministratore attivo sulla rete.

Nel momento in cui mi imbatto in una domanda come questa, sono sempre costretta a dire "Sì, elimina gli account inattivi". Perché? Perché è una "buona pratica" rimuovere vecchi account che non sono più in uso. Alcuni casi d'uso che sono borderline applicabili a questo scenario:

• Riutilizzo del nome utente: se i nomi utente sono "gclooney" anziché "admin22", si verificano collisioni minori durante la creazione di nomi utente se un nuovo amministratore risolve lo stesso nome utente / handle
• Spreco di risorse: sono d'accordo che non stiamo più eseguendo un'applicazione su un Raspberry Pi. Ma ancora, è spreco di memoria e anche un controllo aggiuntivo. Non solo ora controlli se il nome utente è corretto, ma avresti anche bisogno di un controllo aggiuntivo per la loro validità.
• Enumerazione non necessaria: supponendo una fuga di dati / SQL injection porta a perdite di informazioni utente (admin), ora si corre il rischio di far filtrare più informazioni del necessario, se si dice che anche il nome e il cognome dell'ex-admin sono memorizzati in un record DB correlato.
• Il punto di grochmal sulle linee guida OWASP.

Scambia sempre il lato più sicuro e supponi che il cattivo possa trasformare le cose più strane a loro vantaggio!

Is it more beneficial or less

La domanda è: "Quali potrebbero essere i motivi per NON eliminarli?" Cosa potrebbe esserci di meno vantaggioso? Ci sono molte più ragioni, (come hanno menzionato gli altri utenti), per eliminarle, quindi per non farlo.

Eliminazione: < 30 minuti

! eliminazione: > molti giorni di ripristino di emergenza

Modifica

In risposta a Kzqai

Se il tuo database è configurato correttamente, dovresti avere gli utenti nella loro tabella. Quindi la loro storia mi piacerebbe far parte di un tavolo diverso. E se no, ti suggerisco di rivalutare la configurazione del tuo database. Inoltre, se si seguono le buone pratiche, è necessario disporre di backup del database che è possibile fare riferimento in caso si guardino gli utenti vecchi / eliminati. Ma realisticamente, se il database è configurato bene, puoi eliminare un utente, senza effetti di impatto su qualsiasi altra cosa legata a quell'utente.