Quand dois-je créer un nouveau compte utilisateur pour exécuter des logiciels sur un serveur?

En général, quand doit-on créer un nouveau compte utilisateur pour exécuter un logiciel Internet sur un serveur?

Par exemple, supposons que j'utilise un serveur Debian partagé (par exemple via Dreamhost) et que je souhaite exécuter certains sites Web en utilisant WordPress, certains en utilisant Redmine, certains en utilisant Ruby on Rails, peut-être certains en utilisant Django, et j'aimerais servir Mercurial référentiels aussi.

Sur les serveurs Dreamhost et de nombreux autres serveurs de configuration similaire, cela pourrait être fait sous un seul compte utilisateur , mais je peux voir quelques inconvénients à cette approche:

• Un .bashrc plus long
• Si ce compte est compromis, il en va de même pour tous les sites fonctionnant sous celui-ci.

D'un autre côté, avoir beaucoup de comptes d'utilisateurs pourrait devenir un peu difficile à suivre, surtout si certains d'entre eux ont des exigences identiques en termes de logiciels installés. Par exemple, avoir un compte pour chaque site Web exécutant WordPress peut être exagéré.

Quelle est la meilleure pratique? S'agit-il simplement de réduire le nombre de sites hébergés (ou référentiels hébergés, etc.) par compte utilisateur proportionnellement à son niveau de paranoïa?

Veuillez publier vos opinions à ce sujet, en indiquant vos raisons.

De plus, si vous avez des raisons de penser que l'approche adoptée sur un serveur privé ou VPS devrait différer de l'approche adoptée sur un serveur partagé, veuillez décrire ce qu'elles sont et, encore une fois, vos raisons.

Je suis généralement un fan de "Un utilisateur pour tout ce qui ouvre la prise d'écoute sur le réseau" - Un pour Apache, un pour Mail, un pour DNS, etc.

C'est (comme je l'ai entendu la dernière fois) toujours la meilleure pratique actuelle, et la raison derrière cela est une paranoïa simple et simple: ces services sont exposés au Big Bad Internet, si quelqu'un trouve une vulnérabilité et l'exploite avant d'avoir la chance de corriger le au moins je les limite à un seul compte utilisateur, avec seulement les privilèges requis pour exécuter le service unique dont il est responsable.
De manière générale, je considère que ce niveau d'isolement est suffisant pour protéger le système, bien que chaque application soit un îlot de vulnérabilité (par exemple, si quelqu'un installe un plugin WordPress vulnérable, toutes les choses auxquelles Apache a accès (c'est-à-dire tous les sites Web) sont effectivement vulnérables en cas de compromis.

Une version étendue de cet argument peut ainsi être faite pour les sites Web des clients d'hébergement partagé en sandbox avec sa propre configuration et utilisateur Apache (vous n'avez pas nécessairement à installer une pile Web complète pour chaque site, juste une configuration Apache distincte spécifiant un utilisateur différent ), l'inconvénient étant que chaque site exécute maintenant un tas de processus Apache, donc votre utilisation de la RAM a augmenté de manière substantielle, et les choses lisibles par le monde sont toujours vulnérables si une seule instance / utilisateur Apache est compromis.

Étendre davantage l'argument pour mettre chaque Apache dans un chroot (ou une prison si vous sur des systèmes BSD) peut être fait pour encore plus de sécurité, mais maintenant vous parlez d'espace disque supplémentaire car chaque chroot / prison aura besoin de tous les logiciels nécessaires pour exécutez le site qu'il contient (et la nécessité de mettre à jour ce logiciel pour chaque site plutôt qu'une seule copie principale sur le serveur lorsque les correctifs sortent), plus l'exigence de RAM, tout comme lorsque vous aviez des instances utilisateurs / apache distinctes.
Cela atténue tout sauf un bogue OS / noyau qui permet aux utilisateurs de sortir du chroot (qui devient l'argument pour exécuter chaque site sur un serveur physique séparé - qui devient alors l'argment pour séparer les sites en différents réseaux virtuels / sous-réseaux, etc.)

Comme pour tous les risques, vous ne pouvez pas l'éliminer: vous ne pouvez l'atténuer qu'à un niveau acceptable en fonction du préjudice / coût potentiel d'un compromis, de la probabilité d'un compromis et du coût de chaque niveau d'atténuation.
Pour mon argent, pour un environnement d'hébergement partagé non critique et non E-Commerce, le "Un utilisateur pour Apache, un pour DNS, un pour le courrier, etc." un filet de sécurité suffit. S'il existe un besoin de sécurité au-delà de ce niveau, vos utilisateurs devraient sérieusement envisager leur propre matériel.

Généralement, ce que je fais est d'avoir un utilisateur pour les services externes qui n'est pas autorisé à se connecter ("personne" par exemple), et un compte qui est autorisé à se connecter et su ou sudo. Assurez-vous naturellement que vos noms d'utilisateur sont différents et difficiles à deviner.

Je ne vois pas d'avoir un utilisateur par service comme nécessaire, sauf si vous exécutez un environnement d'hébergement partagé où chaque client a une connexion. Si vous vous voyez de manière réaliste comme une cible très intéressante pour le piratage, vous pouvez aussi bien isoler autant que possible. Cependant, à moins que vous ne fassiez quelque chose de très controversé ou que vous hébergiez des données financières, vous n'êtes pas vraiment attrayant pour une cible.