Quelle est la différence entre un compte utilisateur et un compte de service?

Je voudrais connaître la différence entre l'utilisateur et le compte de service.

Je sais que par exemple Jenkinsinstallé sur ubuntu n'est pas un utilisateur, mais un compte de service .

1. Quelle est l'utilisation du compte de service?
2. Quand en avons-nous besoin?
3. Comment puis-je créer un compte de service?

Les comptes d'utilisateurs sont utilisés par de vrais utilisateurs, les comptes de services sont utilisés par les services système tels que les serveurs Web, les agents de transport de messagerie, les bases de données, etc. . À l'exception de l'UID 0, les comptes de service n'ont aucun privilège spécial. Les comptes de service peuvent posséder - et possèdent généralement - des ressources spécifiques, même des fichiers spéciaux de périphérique, mais ils n'ont pas de privilèges de type superutilisateur.

Les comptes de service peuvent être créés comme des comptes d'utilisateurs ordinaires (par exemple en utilisant useradd). Cependant, les comptes de service sont généralement créés et configurés par le gestionnaire de packages lors de l'installation du logiciel de service. Ainsi, même en tant qu'administrateur, vous devez rarement être directement concerné par la création de comptes de service.

Pour une bonne raison: contrairement aux comptes d'utilisateurs, les comptes de service n'ont souvent pas de shell de connexion "approprié", c'est-à-dire qu'ils ont un /usr/sbin/nologinshell de connexion (ou, dans le passé /bin/false). De plus, les comptes de service sont généralement verrouillés, c'est-à-dire qu'il n'est pas possible de se connecter (pour les traditionnels /etc/passwdet /etc/shadowcela peut être obtenu en définissant le hachage du mot de passe sur des valeurs arbitraires telles que *ou x). Il s'agit de durcir les comptes de service contre les abus ( défense en profondeur ).

Le fait d'avoir des comptes de service individuels pour chaque service sert deux objectifs principaux: c'est une mesure de sécurité pour réduire l'impact en cas d'incident avec un service ( compartimentage ), et cela simplifie l'administration car il devient plus facile de retracer quelles ressources appartiennent à quel service. . Voir ceci ou ces réponses sur des questions connexes pour plus de détails.

À l'origine, les utilisateurs devaient correspondre à un humain utilisant le système, d'où le nom. Chaque processus s'exécute en tant qu'utilisateur particulier et chaque fichier appartient à un utilisateur particulier. Un utilisateur spécial, appelé root, est utilisé pour des choses qui n'appartiennent à aucun utilisateur humain particulier, c'est-à-dire le système d'exploitation lui-même. Étant donné que root correspond au système d'exploitation lui-même, il dispose de tous les privilèges.

Bientôt, les gens ont trouvé qu'il était pratique de créer plusieurs utilisateurs du système, sans privilèges étendus. Cela permet d'isoler les différents services qui s'exécutent sur une machine, afin qu'ils ne marchent pas les uns sur les autres. Un compte de service (ou «compte système», ces deux termes sont synonymes) est celui qui correspond à un service exécuté sur le système, plutôt qu'à une personne utilisant le système. Vous avez généralement un compte de service pour chaque tâche exécutée sur le système qui possède son propre ensemble de privilèges (par exemple ses propres fichiers, ses propres ports réseau, etc.).

Il n'y a pas de définition formelle du compte humain vs système / service. Le noyau s'en fiche (à part l'octroi de nombreux privilèges à l'utilisateur avec l'UID 0). La plupart des commandes d'administration ne se soucient pas non plus. Certaines différences typiques sont:

• Un utilisateur humain a un vrai nom comme «John Doe», tandis qu'un utilisateur système a un nom descriptif comme «démon nasal» ou aucun.
• Un utilisateur humain a un véritable shell de connexion (par exemple /bin/shou /bin/bashou /bin/csh. Certains utilisateurs du système ont un shell (presque toujours /bin/sh), d'autres pas, selon la façon dont ils sont destinés à être utilisés (par exemple, su foonécessitefoo d'avoir un shell).
• Un utilisateur humain a souvent un mot de passe - mais ce n'est pas toujours le cas, par exemple un utilisateur distant uniquement peut ne disposer que d'une clé SSH. Notez que sur les unités modernes, le mot de passe n'est pas dans /etc/passwdmais dans un autre fichier tel que/etc/shadow .
• Le répertoire de base d'un utilisateur humain est généralement sous /home(ou un emplacement spécifique au site), tandis que le répertoire de base d'un utilisateur système n'est généralement pas sous/home et peut ne pas exister (mais il existe des exceptions).
• La plupart des sites désignent une plage d'ID utilisateur pour les utilisateurs du système et une plage disjointe pour les utilisateurs humains. La réservation de 100–65533 ou 500–65533 ou 1000–65533 est typique, et la plupart des distributions sont configurées pour commencer à allouer des ID utilisateur réels à partir de 500 ou 1000.

Sur les sites où les comptes sont partagés sur plusieurs machines, il existe généralement un serveur central qui contient des listes d'utilisateurs, accessibles via NIS ou LDAP . L' passwdentrée dans /etc/nsswitch.confspécifie où trouver les informations utilisateur. Il est courant d'avoir des utilisateurs du système au niveau local/etc/passwd et réels de la base de données à l'échelle du réseau, mais parfois il y a des utilisateurs système dans la base de données à l'échelle du réseau (pour appliquer des UID cohérents, ce qui facilite la réplication du serveur et des données), et parfois il y a utilisateurs humains dans le fichier local (pour leur permettre de se connecter même lorsque le réseau est arrosé).

Un compte accessible à l'homme déguisé en utilisateur système n'aurait généralement pas de vrai nom, mais aurait un shell de connexion, et soit un mot de passe, soit une clé SSH, tout en ayant un ID utilisateur dans la plage système. En fait, ce serait un meilleur déguisement d'utiliser un compte système réel dont la suppression entraînerait l'arrêt de certains services. Mais vous ne pouvez pas avoir de règles strictes pour détecter les attaques potentielles: par définition, les attaquants ne suivent pas les règles.

Les comptes de service et les comptes humains sont gérés par les mêmes commandes et enregistrés dans les mêmes fichiers. Les commandes de création de compte peuvent avoir des options pour définir des valeurs par défaut raisonnables pour les utilisateurs humains vs services, par exemple pour choisir un ID utilisateur dans la plage appropriée, et pour demander un mot de passe pour un humain et désactiver l'authentification par mot de passe pour un service. Par exemple, adduservs adduser --systemou useraddvs useradd -rsous Linux.

• 1. un compte de service, également appelé compte technique, est un compte conçu pour être utilisé uniquement par un service / une application, et non par un utilisateur régulier.
• 2. Les développeurs d'applications et de services souhaitent que ces comptes restreignent les droits et privilèges des processus associés au lieu d'exécuter leurs processus en tant que root. Les services démarrés par init, systemdou similaires, qui s'exécutent en tant que root, rétrogradent rapidement vers le compte de service pour limiter les risques. Selon le système d'exploitation utilisé, les comptes d'application peuvent bénéficier de plus de privilèges que les comptes réguliers, par exemple le droit de se lier à un port TCP privilégié, ou au contraire de voir leurs privilèges réduits par rapport à un utilisateur normal, par exemple en refusant les processus de service à appeler fork/ exec. Dans ce cas, il n'est pas nécessaire que les services soient rétrogradés vers le compte de service, ils peuvent être démarrés avec celui-ci.
• 3. Vous ne devriez pas avoir besoin de créer un compte sans mot de passe utilisable et avec un shell non fonctionnel (par exemple /bin/false) et il ne sera pas utilisable par un utilisateur régulier, c'est-à-dire qu'il n'y aura aucun moyen de se connecter localement ou à distance (par exemple à travers ssh) en utilisant le nom du compte. Comme la plupart des limitations, utiliser le compte root ou sudopermet de le surmonter.

Un compte de service peut ne pas avoir la possibilité d'utiliser un shell par exemple. Il est utilisé pour exécuter des services (démon) avec une portée et des privilèges restreints. Mon avis est que vous pouvez le créer en tant qu'utilisateur régulier, tout en faisant attention aux droits et à l'appartenance au groupe. Cependant, la plupart du temps, ce n'est pas le cas, car les programmes les créent automatiquement lors de l'installation. Jetez un oeil dans/etc/passwd root:x:0:0:root:/root:/bin/bash

0 est l'UID, il caractérise la hiérarchie du compte dans l'espace utilisateur, la racine est au-dessus de tout le monde, puis vous avez l'appartenance au groupe :rootle répertoire personnel /rootenfin le shell utilisé par le compte /bin/bashpour `` se connecter '' au système.

Vous pouvez utiliser /usr/sbin/nologinun compte pour lequel vous ne souhaitez pas de privilège de connexion.