Pourquoi les entreprises n'accordent-elles pas un accès root aux employés sur leurs ordinateurs de bureau?
Pourquoi les entreprises n'accordent-elles généralement pas à leurs employés un accès root à leurs ordinateurs de bureau qui ne sont utilisés que par un seul employé?
Si ce que je peux faire sur ma machine constitue une menace pour le reste du réseau, n'est-ce pas une faille de sécurité en soi? Pourquoi les droits que j'ai sur ma propre machine affectent-ils ce que je peux faire aux autres sur le réseau?
Le but de la gestion des utilisateurs Unix n'est-il pas de protéger les fichiers de l'utilisateur A sur la machine X contre l'accès par l'utilisateur B sur la machine X?
S'il s'agit de protéger l'utilisateur de lui-même (par exemple, d'installer quelque chose avec un accès root qui effacera le disque dur): Puisque je travaille sans accès root, tous mes fichiers appartiennent à moi-même; Par conséquent, si je suis dupe et que j'exécute un mauvais script sans accès root et qu'il efface tous les fichiers appartenant à moi-même, c'est tout aussi mauvais que si je lui avais donné un accès root et qu'il avait effacé tout le disque dur.
Les administrateurs de sécurité sont responsables de votre machine et de ce qui se passe sur votre machine. Cette responsabilité viole le modèle de sécurité de base pour une machine Unix à utilisateur unique car l'administrateur (une partie absente) est root sur votre machine, vous ne sont pas. Unix n'est pas vraiment configuré pour ce modèle.
Les administrateurs doivent pouvoir installer des contrôles de sécurité sur votre machine afin de protéger l'entreprise, pas seulement les données, le réseau et les autres nœuds. Si l'utilisateur local avait un accès root, les administrateurs ne contrôlent plus ces contrôles. C'est la prémisse de base.
Oui, il y a des tonnes de raisons pour lesquelles root est nécessaire pour faire de mauvaises choses ou pour transformer la machine en un nœud malveillant et toutes ces raisons sont bonnes pour ne pas fournir un accès root. Et oui, il existe de nombreuses façons de contourner ces limitations et de nombreuses façons dont l'utilisateur local pourrait faire de mauvaises choses. Mais finalement, l'utilisateur local et le propriétaire du risque ne peuvent pas être en concurrence pour le contrôle ou la responsabilité de la machine.
Quelques raisons du haut de ma tête:
Les attaques d'empoisonnement ARP ou d'inondation du réseau sur le réseau nécessitent généralement un accès root à une machine du réseau.
La possibilité d'installer des programmes non autorisés peut ouvrir la société à une responsabilité légale si ces programmes sont eux-mêmes illégaux (par exemple parce qu'ils sont piratés ou non autorisés à des fins lucratives ou autre).
Si l'entreprise a une sorte de surveillance à distance des employés (ou souhaite avoir la possibilité d'avoir une telle surveillance même si elle n'est pas encore en place), donner aux utilisateurs un accès root leur permettrait de contourner cela.
Ne pas avoir accès root signifie que vous ne pouvez pas
rm -rf /bin, ou un certain nombre d'autres choses destructrices, et toute personne qui accède à vos informations de connexion ne peut pas non plus, il n'y a donc aucune chance que votre entreprise ait besoin de vous aider à vous remettre de cette situation.Si votre entreprise peut redéployer votre machine si vous quittez, elle peut se sentir plus à l'aise de le faire sans effectuer un nettoyage et une réinstallation complets si vous n'y avez jamais eu accès root.
Donner aux utilisateurs un accès root est facile, si cela devient nécessaire; retirer complètement l'accès root est difficile s'il devient nécessaire.
Le principe général principe du moindre privilège est que vous ne devez pas donner à quiconque/quoi que ce soit un accès dont ils n'ont pas besoin activement.
Tout simplement ne pas être passé du temps des serveurs partagés car c'est un processus qui a fonctionné et rien n'a brisé l'inertie (l'hypothèse problème des singes et des échelles ).
Cette réponse n'est pas destinée à contredire les réponses existantes, mais plutôt à les compléter car elle est trop longue pour un commentaire.
Une partie de la raison est (comme d'autres l'ont fait allusion) qu'on ne peut pas faire confiance aux utilisateurs pour ne pas faire des choses stupides/malveillantes. Mais une autre partie est à qui incombe la responsabilité de réparer les choses lorsque cela se produit?
Je suis développeur full-stack et devops à temps partiel avec un accès root non seulement à mes propres machines de développement, mais à un certain nombre de nos serveurs de production et au moins un certain niveau d'accès à l'hyperviseur sur lequel ils sont déployés. Mais si je me trompe, je suis le parti (ou du moins a parti) avec les compétences, l'expertise et la responsabilité de le réparer. Ce n'est pas le cas de l'utilisateur final typique: si Bobby l'utilisateur fausse son installation Windows qui contenait des données essentielles à la mission et/ou était utilisé pour un travail critique, alors Bobby n'est pas celui qui doit intervenir sur son/sa journée de congé ou de faire des heures supplémentaires non rémunérées pour y remédier. Sans parler de la réponse aux cuivres comment Bobby a réussi à couler presque à lui seul le navire.
Ainsi, une partie de la raison pour laquelle les services informatiques limitent les privilèges des utilisateurs finaux est qu'elle réduit leur propre exposition aux risques.
AFAIK, il y a 4 raisons principales de ne pas donner l'accès administrateur à tilisateurs standard sur leurs bureaux:
- protéger la machine elle-même (pas toujours très efficace) et les autres machines du réseau contre d'éventuelles attaques utilisant cette machine comme relais (déjà couvert par d'autres réponses)
- protéger l'équipe de support informatique contre les attaques de niveau administrateur qui nécessiteront beaucoup de travail à corriger (déjà couvert par d'autres réponses)
- garder toutes les machines avec (plus ou moins) la même configuration pour pouvoir effectuer simplement des déploiements à distance à partir d'une seule machine d'administration - la plus petite taille de l'équipe de support, la moins chère pour l'entreprise
- empêcher (ou du moins essayer) aux utilisateurs d'installer des programmes sans rapport avec leur travail - un utilisateur qui joue à des jeux au travail ou qui conçoit sa future cuisine n'est pas très productif ...
Mais il ne peut pas protéger les données sur la machine ni plus généralement les données accessibles à l'utilisateur, que ce soit sur la machine locale ou sur un serveur. C'est là que les sauvegardes viennent à la rescousse.
Votre machine n'est pas seulement utilisée par vous. Il est également utilisé par votre équipe d'assistance de bureau.
Si j'ai un accès root à une boîte - en particulier une boîte Windows jointe à un domaine - je peux installer un nombre illimité de trucs différents que je pourrais utiliser pour compromettre tout autre utilisateur de la boîte. Disons, par exemple, un enregistreur de frappe.
Ensuite, tout ce que je dois faire est de persuader un ingénieur de support de se connecter pour résoudre un "problème" fraîchement fabriqué (tel que la rupture du secret partagé de Kerberos), d'attendre qu'il passe à l'administrateur du domaine et je viens de compromettre l'ensemble du réseau.
L'enregistreur de frappe ne sera-t-il pas détecté par le scanner de logiciels malveillants? Pas si j'ai root, ce ne sera pas le cas.
Vous obtenez ce dont vous avez besoin pour faire votre travail. Si votre travail nécessite un accès root, vous l'obtenez - ainsi que le discours sur le pouvoir/la responsabilité associé. Mon travail consiste à protéger tout le monde contre vous.
Si vous voulez vraiment rooter sur votre poste de travail personnel, pensez au BYOD - mais si vous le cassez, vous le réparez.
L'entreprise doit protéger les choses. Ils doivent protéger leur secret commercial, mais ils doivent également protéger des éléments tels que les données des utilisateurs. Si chaque employé a une autre configuration éventuellement non sécurisée sur son bureau, l'entreprise n'a aucune chance de s'assurer qu'il n'y a pas de vol de données ni de perte de données. Une gestion centralisée par des professionnels permet de sécuriser les ordinateurs et d'éviter les pertes de données accidentelles.
Dans le cas d'une boîte Unix connectée à tout type de serveurs de fichiers NFS old school (v2 ou v3), l'accès root local permet effectivement à un utilisateur d'interférer avec les fichiers d'autres utilisateurs, car l'autorisation est partiellement implémentée côté client avec ces protocoles, tandis que l'authentification est sous le contrôle des utilisateurs locaux de cette façon. Cela signifie que quelqu'un peut simplement accéder à un compte utilisateur existant ou créé avec le même uid et avoir accès aux fichiers appartenant à cet uid sur NFS.
De plus, "n'est utilisé que par un seul employé" est la façon définitive ou habituelle de travailler là-bas? Si les machines font partie d'un domaine d'authentification commun, parfois échangées entre les utilisateurs selon les besoins, ou si l'accès aux machines des collègues (mais pas leurs données!) Est parfois autorisé, cela ressemble à un scénario mono-utilisateur pur, mais il utilise en fait des fonctionnalités multi-utilisateurs pour la gestion de l'équipement fins.
À partir d'une licence de logiciel POV, je ne veux pas que les utilisateurs puissent installer des logiciels à volonté. Par exemple, un utilisateur souhaite installer Sublime Text, un éditeur de texte qui permet de l'utiliser gratuitement pendant une durée limitée. Il le supprime et le réinstalle après le temps imparti. Cela violerait le CLUF.