Quando devo creare un nuovo account utente per eseguire il software su un server?

In generale, quando si dovrebbe creare un nuovo account utente per eseguire un software per Internet su un server?

Ad esempio, supponiamo che io stia usando un server Debian condiviso (ad esempio tramite Dreamhost) e che voglia eseguire alcuni siti Web usando WordPress, alcuni usando Redmine, altri usando Ruby on Rails, forse alcuni usando Django, e mi piacerebbe servire Mercurial anche i repository.

Sui server Dreamhost e molti altri server configurati in modo simile, tutto ciò potrebbe essere fatto con un singolo account utente , ma posso riscontrare alcuni svantaggi di tale approccio:

• Un .bashrc più lungo
• Se quell'account viene compromesso, lo stesso vale per tutti i siti in esecuzione al suo interno.

D'altra parte, avere molti account utente potrebbe essere un po 'difficile da tenere traccia, soprattutto se alcuni di essi hanno requisiti identici in termini di software installato. Ad esempio, avere un account per ogni sito Web che esegue WordPress potrebbe essere eccessivo.

Qual è la migliore pratica? Si tratta semplicemente di ridurre il numero di siti ospitati (o repository ospitati, ecc.) Per account utente in proporzione al proprio livello di paranoia?

Si prega di pubblicare le vostre opinioni su questo, fornendo i motivi per cui.

Inoltre, se hai qualche motivo per pensare che l'approccio adottato su un server privato o VPS dovrebbe differire dall'approccio adottato su un server condiviso, ti preghiamo di delineare quali sono e, ancora, le tue ragioni.

In genere sono un fan di "Un utente per tutto ciò che apre socket di ascolto sulla rete" - Uno per Apache, uno per Mail, uno per DNS, ecc.

Questa è (come ho sentito l'ultima volta) ancora la migliore prassi corrente e il motivo alla base di questa è una paranoia semplice e chiara: questi servizi sono esposti alla Big Bad Internet, se qualcuno trova una vulnerabilità e la sfrutta prima che io abbia la possibilità di rattoppare il almeno il software li sto limitando a un account utente, con solo i privilegi richiesti per eseguire il singolo servizio di cui è responsabile.
In generale, considero questo livello di isolamento sufficiente per proteggere il sistema, sebbene ogni applicazione sia un'isola di vulnerabilità (ad esempio se qualcuno installa un plugin WordPress vulnerabile, tutte le cose a cui Apache ha accesso (ovvero tutti i siti Web) sono effettivamente vulnerabili in caso di compromesso.

È quindi possibile creare una versione estesa di tale argomento per il sandbox dei siti Web dei client di hosting condiviso con la propria configurazione e utente Apache (non è necessario installare uno stack Web completo per ciascun sito, ma solo una configurazione apache separata che specifica un utente diverso ), il rovescio della medaglia è che ogni sito sta eseguendo un sacco di processi Apache, quindi l'utilizzo della RAM è aumentato in modo sostanziale e le cose leggibili dal mondo sono ancora vulnerabili se una singola istanza / utente di Apache viene compromessa.

Estendere ulteriormente l'argomento per mettere ogni Apache in un chroot (o prigione se si è su sistemi BSD) può essere fatto per una sicurezza ancora maggiore, ma ora stai parlando di spazio su disco aggiuntivo poiché ogni chroot / jail avrà bisogno di tutto il software necessario per eseguire il sito in esso contenuto (e la necessità di aggiornare questo software per ogni sito anziché una sola copia master sul server quando escono le patch), oltre al requisito di RAM proprio come quando si avevano utenti / istanze separate di apache.
Ciò mitiga tutto tranne un bug OS / Kernel che consente agli utenti di uscire dal chroot (che diventa l'argomento per l'esecuzione di ogni sito su un server fisico separato - che diventa quindi l'argomento per separare i siti in diversi vlans / subnet, ecc.)

Come per tutti i rischi, non è possibile eliminarlo: è possibile solo mitigarlo fino a un livello accettabile in base al potenziale danno / costo di un compromesso, alla probabilità di un compromesso e al costo di ciascun livello di mitigazione.
Per i miei soldi, per un ambiente di hosting condiviso non critico, non di e-commerce, "un utente per Apache, uno per DNS, uno per posta, ecc." la rete di sicurezza è sufficiente. Se c'è una necessità di sicurezza oltre quel livello, gli utenti dovrebbero considerare seriamente il proprio hardware.

Generalmente quello che faccio è avere un utente per i servizi di rivestimento esterno a cui non è consentito il login ("nessuno" per esempio) e un account a cui è consentito il login e su o sudo. Naturalmente assicurati che i tuoi nomi utente siano diversi e non facilmente indovinabili.

Non vedo che un utente per servizio è necessario a meno che tu non stia eseguendo un ambiente di hosting condiviso in cui ogni cliente ha un accesso. Se ti vedi realisticamente come un bersaglio molto attraente per l'hacking, puoi anche isolare il più possibile. Tuttavia, a meno che tu non stia facendo qualcosa di molto controverso o non stia ospitando dati finanziari, non sei davvero così attraente per un obiettivo.