Dividi un'applicazione in parti utente e amministratore per motivi di sicurezza?

Sì, è una buona idea: se l'applicazione lo consente, renderà possibile applicare il principio del minimo privilegio una distribuzione, ad esempio assicurandosi che l'interfaccia amministrativa possa essere raggiunta solo da reti "sicure".

Può essere ulteriormente migliorato applicando lo stesso principio in tutto lo stack: utilizzando il sistema operativo e i sistemi di sicurezza del database per assicurarsi che diversi elementi dell'applicazione abbiano accesso solo alla parte dei dati di cui hanno realmente bisogno.

Il rischio principale è sovra-ingegnerizzare tutto: suddividere l'applicazione significa definire un meccanismo per le diverse parti da comunicare insieme (API). Questo è spesso un aspetto trascurato della sicurezza delle applicazioni che può aumentare la superficie di attacco di un potenziale aggressore.

Come Stephane, sono d'accordo che può aiutare la tua sicurezza, ma è un esempio:

Diciamo che hai i tuoi "dati utente" da qualche parte nella tua applicazione, che contiene indirizzi email, nomi utente e password. (Probabilmente in un DB)

Potresti creare due account DB. Un account è chiamato "Nessuno" e l'altro è chiamato "Amministratore".

"Nessuno" è usato dal tuo sito normale e ha la capacità di:

• Crea un account
• Chiedi al DB la combinazione utente + password è corretta
• Modifica la password, se la vecchia password viene fornita con la nuova password

"Admin" d'altra parte ha pieno accesso a quella tabella e può fare tutto ciò che vuole.

Il vantaggio di fare le cose in questo modo è che anche se il tuo sito pubblico è compromesso, l'utente malintenzionato non ha (ancora) accesso completo a tutte le tue password con hash. La tua pulizia sarà ancora un disastro, ma meno caos che se potesse leggere o modificare i tuoi account utente a volontà.

E sì, ho ignorato molti dettagli, come quello che succede se qualcuno dimentica la loro password.