¿Dividir una aplicación en partes de usuario y administrador por razones de seguridad?

Sí, es una buena idea: si la aplicación lo permite, será posible aplicar el principio del menor privilegio a una implementación, por ejemplo, asegurándose de que solo se pueda acceder a la interfaz administrativa desde redes "seguras".

Se puede mejorar aún más aplicando el mismo principio en toda la pila: usar el sistema operativo y los sistemas de seguridad de la base de datos para garantizar que los diferentes elementos de la aplicación solo tengan acceso a la parte de los datos que realmente necesitan.

El principal riesgo es sobre-diseñar todo: dividir la aplicación significa definir un mecanismo para que las diferentes partes se comuniquen entre sí (API). A menudo, este es un aspecto que se pasa por alto en la seguridad de la aplicación y puede aumentar la superficie de ataque de un posible atacante.

Al igual que Stephane, estoy de acuerdo en que puede ayudar a tu seguridad, pero con un ejemplo:

Supongamos que tiene sus "datos de usuario" en alguna parte de su aplicación, que contienen direcciones de correo electrónico, nombres de usuario y contraseñas. (Probablemente en un DB)

Podrías crear dos cuentas DB. Una cuenta se llama "Nadie" y la otra se llama "Admin".

Su sitio normal usa "Nadie" y tiene la capacidad de:

• Crear una cuenta
• Pregunte si la base de datos es usuario + la combinación de contraseña es correcta
• Cambie la contraseña, si la contraseña anterior se suministra con la nueva contraseña

"Admin", por otro lado, tiene acceso completo a esa tabla y puede hacer lo que quiera.

La ventaja de hacer las cosas de esta manera es que incluso si su sitio público está comprometido, el atacante no tiene (aún) acceso completo a todas sus contraseñas de hash. Su limpieza seguirá siendo un desastre, pero menos que si él pudiera leer o modificar sus cuentas de usuario a voluntad.

Y sí, me ignoran muchos detalles, como qué sucede si alguien olvida su contraseña.