Lorsqu'un dæmon se voit compromis, par exemple, par un débordement de pile, l'attaquant peut exécuter du code (des ordres) avec les droit de ce dæmon. Si ce serveur fonctionne avec les droits de l'utilisateur root, le code « injecté » par l'attaquant aura lui aussi les droits de root. On comprend donc l'interêt d'exécuter ce logiciel (par exemple, le serveur web apache) avec des droits minimum. En général, lorsqu'un logiciel type dæmon est installé sur un serveur, un utilisateur spécial est créé à cet effet afin de limiter la casse en cas d'intrusion.

Ce principe de privilège minimum s'applique aussi aux utilisateurs. Il faut restreindre les droits affectés aux utilisateurs en fonction de leur besoin. Ce n'est pas uniquement une question de confiance : le compte de l'utilisateur peut être compromis, l'utilisateur peut ne pas avoir conscience des problèmes liés à la sécurité, etc... Il faut donc là aussi fournir le minimum de privilèges à l'utilisateur afin d'éviter une catastrophe démesurée par rapport aux droits réèllement requis pour cet utilisateur. A titre d'exemple, imaginons qu'un utilisateur doive envoyer des fichiers sur un serveur web. Si l'administrateur du serveur se contente de créer un compte à cet utilisateur, il possèdera par défaut un shell. Ce shell pourra éventuellement être utilisé via ssh, ou au travers d'une application Web mal programmée, ou en local sur la console. Si le seul besoin est d'envoyer des fichiers, l'utilisateur ne doit pouvoir faire que cela.

	Privilège minimum
	Appliquer le principe du privilège minimum, aussi bien aux applications qu'aux utilisateurs

Le corolaire au privilège minimum est la séparation des pouvoirs. A l'instar des pouvoirs législatifs et exécutifs que nous connaissons ailleurs, une machine ne doit pas offrir des services, qui, cumulés, lui donneraient un pouvoir trop important sur l'activité du site. C'est une question de résilience du système d'information, mais c'est surtout un prérequis permettant d'éviter une éventuelle escalade de privilèges. Il est à déconseiller, par exemple, d'installer une autorité de certification (CA) ^[4] sur une machine fournissant un autre service. Idem pour les serveurs DNS, LDAP, SQL, qui contiennent ou servent souvent des éléments utilisés dans la sécurité d'autres machines (authentification, noms d'hôtes, ...) revétant ainsi une importance toute particulière. Il en va de même pour les utilisateurs à pouvoir : il faut séparer les pouvoirs afin d'avoir des gardes fous sur l'utilisation qui est faite du système d'information. Un chef d'entreprise ne devrait pas, par exemple, gérer la messagerie de ses employés, afin d'éviter toute tentation offerte par l'accès aux boîtes.

	Séparation des pouvoirs
	Appliquer la séparation des pouvoirs, aussi bien aux machines qu'a leurs administrateurs