Alice et Eve travaillent pour Bob. Alice est une très bonne travailleuse qui fait exactement ce que Bob lui demande de faire. Eve est un cerveau criminel déterminé à détruire l'entreprise de Bob.

Alice et Eve partagent le même compte.

Eve se connecte au compte et l'utilise pour saboter un processus commercial important . Le journal d'audit capture cette action.

Comment Bob sait-il qui a saboté son entreprise? Il doit se débarrasser du mauvais acteur, mais ne peut pas les renvoyer tous les deux, car son entreprise dépend du travail qu'ils font. Il ne pourrait en tirer qu'un seul, mais il n'a aucun moyen de savoir lequel est son ami et lequel est son ennemi.

Si Alice et Eve avaient des comptes séparés, Bob pourrait être sûr qu'Eve était celle qui a fait le sabotage. Eve pourrait même éviter de faire le sabotage, si elle sait que son compte sera audité et qu'elle sera attrapée.

EDIT: Ajout de commentaires:

Si Eve quitte, vous devez maintenant réinitialisez le mot de passe de chaque compte auquel elle avait accès, plutôt que de simplement désactiver ses comptes personnels. C'est beaucoup plus difficile à gérer et vous allez manquer des comptes.

De plus, cela vous empêche d'avoir un contrôle granulaire sur l'accès. Si Alice doit rédiger des chèques et qu'Eve doit les signer, vous n'avez essentiellement aucun moyen technologique de les faire respecter s'ils partagent le même compte.

De plus, il est plus difficile pour une personne donnée de remarquer des actes malveillants. changements dans leur environnement. Alice sait quels fichiers se trouvent sur le bureau d'Alice. Tout nouveau fichier lèvera probablement un drapeau rouge pour elle. Alice ne sait pas quels fichiers se trouvent sur le bureau partagé d'Alice et Eve. Il est probable que les nouveaux fichiers se heurteront à un haussement d'épaules et à l'hypothèse qu'un autre utilisateur l'aura mis là, pas un acteur malveillant.

Une histoire vraie, qui s'est déroulée sur le lieu de travail d'un ami (juridiction: Allemagne):

Un collègue de ses clients grossièrement insulté via l'e-mail de son entreprise. Elle a été licenciée pour cela. Elle est allée au tribunal. Là, son avocat a informé le tribunal du fait que les employés partageaient leurs mots de passe (par exemple, pour répondre au courrier d'un client en l'absence d'un certain collègue).

Le juge a statué qu'il y avait aucune bonne preuve que la personne en question était vraiment celle qui a envoyé les e-mails insultants. La personne devait être réembauchée et compensée pour la perte de salaire.

Moral: Une fonction des comptes utilisateurs est de discerner les utilisateurs les uns des autres, pour rendre leur action vérifiable. Seuls les comptes privés remplissent cette fonction.

Vous devez utiliser un compte séparé dans tous les contextes (sécurité en haut).
L'exemple Adonalsium vous montre parce que c'est obligatoire. Il y a quelques rares situations où ce n'est "pas possible" ou "pas utile" ...

Exemples: "pas possible" (anciens protocoles / applications) "non pertinent" (actions anonymes)

Si ce n'est pas possible, mais que vous devez identifier, vous devez atténuer le risque d'ajouter plus d'informations sur la source que possible (par exemple, les informations de connexion, l'heure de connexion, etc.)

Vous pouvez consulter la méthodologie d'évaluation des risques ISO 27001, la gestion des risques ISO 31000 comme point de départ pour répondre à votre question "Pourquoi éviter les comptes utilisateurs partagés? "

La réponse typique est la responsabilité, la traçabilité, etc. En d'autres termes, pour être en mesure de savoir qui a fait quoi exactement.

Un compte partagé a n personnes potentielles qui font quelque chose, mais tout ce que vous avez indique qu'un seul compte fait cette chose.

Ce problème est généralement résolu en s'assurant que quelqu'un est légalement responsable des activités de ce compte. Cela peut être faisable ou non, et il se peut que personne ne prenne la responsabilité des actions des autres.

Ce problème survient souvent lorsque vous sous-traitez certaines activités de surveillance - le compte qui effectue les tâches de surveillance doit être contractuel en charge de cette entreprise, qui est responsable de ses actions.

Si vous ne pouvez pas désigner une personne responsable, il appartient alors à la direction de prendre une décision en fonction du risque: ne pas avoir de service vs. savoir qui fait quoi avec ce compte.

Les meilleures pratiques ne sont nulle part "définies", c'est ce que le terme signifie. Une meilleure pratique est simplement une façon établie de faire les choses que la plupart des gens pensent être la meilleure.

Cela va dans le sens inverse. Une fois qu'une «meilleure pratique» est dominante, un membre d'un comité de normalisation décide généralement de l'inclure dans une norme ISO ou une autre norme. Il repose alors là, généralement sans raisonnement explicite, ni raisonnement circulaire soulignant que c'est la meilleure pratique.

Les raisons de cette pratique particulière sont également d'ordre pratique. Si Alice et Bob partagent un compte et que quelque chose de mauvais se produit, ils pointeront tous les deux vers l'autre personne et vous n'avez aucun moyen de savoir qui l'a fait. Avec les comptes personnels, ils prétendront qu'il a été compromis, mais vous avez au moins un seul point à approfondir.

Il existe également des exigences explicites de responsabilité dans de nombreux sous-domaines tels que la conformité, et jouer dedans.

Je ne connais qu'une seule exception à cette règle. Il y a une seule machine qui est partagée par plusieurs utilisateurs, et les affirmations suivantes sont toutes vraies:

• un et un seul de ces utilisateurs est en charge de cette machine à tout moment
• le compte ne peut être utilisé que sur la machine locale - désactivé via le réseau

Cela peut se produire sur les systèmes 7/7 24/24. Dans ce cas d'utilisation, vous gardez toujours une imputabilité acceptable en connaissant l'utilisateur qui était présent à un moment précis, à condition que vous puissiez définir la deuxième règle ci-dessus. Mais en fait, cela revient à avoir un compte sans mot de passe et à n'utiliser que la sécurité physique.

Un autre problème qui n'a pas encore été mentionné est que si quelqu'un reçoit une notification indiquant que son compte est en cours d'accès ou a été consulté à un moment où il n'y a pas / n'y a pas accédé et ne s'attendrait pas à ce que quelqu'un d'autre le fasse , ils sont beaucoup plus susceptibles de déclencher une alarme qu'ils ne le seraient s'ils pensaient que quelqu'un qu'ils avaient autorisé à accéder au compte.

Étant donné le nombre de cas où cela peut être nécessaire pour que quelqu'un autorise quelqu'un d'autre à effectuer une action particulière en son nom, il serait extrêmement utile que les services puissent inclure un moyen par lequel les comptes pourraient autoriser et révoquer des informations d'identification secondaires avec des droits limités. Cela permettrait au système de signaler les informations d'identification utilisées pour accéder à un compte, permettant ainsi à quelqu'un de mieux distinguer les activités attendues des activités inattendues.

Voici quelques points pour une compréhension plus facile et un examen rapide.

Responsabilité

La responsabilité est un autre principe important de la sécurité des informations qui fait référence à la possibilité de retracer les actions et les événements dans le temps jusqu'aux utilisateurs, systèmes ou processus qui les ont exécutés, afin d'établir la responsabilité des actions ou des omissions.

Conformité

Si vous êtes sur la voie de la conformité au RGPD ou à la plupart des réglementations, vous devez être en mesure de définir une ligne sur laquelle chaque compte a accès.

Légal

En cas d'audit, vous devez être en mesure d'identifier les comptes compromis ou responsables d'une action.

Gérer et protéger

Pour protéger, gérer et surveiller le compte, il est plus facile d'avoir un accès individuel séparé pour supprimer, modifier et détecter une utilisation anormale.

Même si vous ne suivez aucune réglementation, vous devez quand même (recommandé) suivre le "b est pratiques "il aide votre processus global de réseau à grande échelle.

Outre le problème d'audit signalé par d'autres réponses, les comptes d'utilisateurs partagés sont intrinsèquement moins sécurisés qu'un compte mono-utilisateur sur la même plate-forme .

Si davantage de personnes connaissent les informations d'identification pour se connecter, ce compte est moins sécurisé. Vous avez maintenant beaucoup plus de victimes potentielles d'attaques d'ingénierie sociale. Chaque personne supplémentaire ayant accès au compte est un autre vecteur d'attaque contre la sécurité de ce compte. Comme le dit le proverbe, deux peuvent garder un secret si l'un est mort.

Je mets également en garde contre l'utilisation de connexions partagées d'un point de vue psychologique. Outre les problèmes d'audit / de culpabilité, les connexions partagées signifient également intrinsèquement partager à la fois la gloire et le blâme. Vous pourriez décourager la responsabilité personnelle et l'éthique de travail. S'il s'agit d'un profil partagé, chaque individu se sentira moins responsable de la sécurité de ce compte. Après tout, même s'ils font toutes les bonnes choses (comme utiliser un gestionnaire de mots de passe et éviter les e-mails de phishing), que faire si leur collègue ne le fait pas? Pourquoi devraient-ils faire un effort supplémentaire alors qu'une autre personne va tout simplement faire la mauvaise chose de toute façon?

De plus, je soupçonne que les connexions partagées auront des mots de passe plus faibles protégeant le compte. Essayer de partager un mot de passe fort et de le gérer correctement entre plusieurs personnes serait peu pratique. Vous vous retrouveriez probablement avec le plus petit dénominateur commun pour la faiblesse du mot de passe ( CompanyName01 ?) Ou un mot de passe écrit physiquement pour que tous dans la zone le voient.

Comme beaucoup l'ont dit, la responsabilité, la traçabilité, la responsabilité, etc. sont les principales raisons. Il y a un certain nombre de points supplémentaires à considérer:

• Dans quelle mesure les informations auxquelles on accède sont-elles secrètes? Dans un cas extrême, de nombreux serveurs FTP publics utilisent (d) un compte partagé «anonyme». Et le compte que vous utilisez pour accéder aux serveurs www publics (un compte non authentifié) n'est-il pas fondamentalement le même? Qu'en est-il des mots de passe WPA2?
• Lorsque vous créez une politique d'entreprise, il est beaucoup plus facile d'appliquer "NE JAMAIS partager des comptes", que "eh bien, vous ne devriez jamais partager un compte, mais dans certains cas, comme un compte en lecture seule sur des informations pas si secrètes pendant une période limitée entre deux personnes qui travaillent ensemble, vous pouvez le faire, si le risque réel est faible ".
• Il y a aussi une charge administrative sur les comptes partagés . Un exemple déjà donné est la nécessité de changer les mots de passe lorsque quelqu'un part.
• Certains comptes doivent être partagés. Un exemple est root sous Unix / Linux. Oui, vous imposerez de nombreuses restrictions sur l'utilisation de root en production, comme sudo avec une journalisation et une surveillance de sécurité étendues, un coffre-fort de mots de passe, etc., mais cela reste est un compte partagé.