Je sais qu'il est préférable de ne pas autoriser les comptes d'utilisateurs partagés, mais où cette meilleure pratique est-elle définie? Est-ce une norme ISO ou quelque chose? Quelles sont les raisons de toujours créer des comptes par personne?
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 la compagnie de Bob.
Alice et Eve partagent toutes les deux le même compte.
Eve se connecte au compte et l'utilise pour saboter un processus métier 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 licencier tous les deux, car son entreprise dépend du travail qu'ils font. Il pourrait tirer 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 pouvait être sûr qu'Eve était celle qui avait fait le sabotage. Eve pourrait même éviter de faire le sabotage, si elle sait que son compte sera audité et qu'elle sera rattrapée.
EDIT: Ajout de commentaires:
Si Eve quitte, vous devez maintenant réinitialiser 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.
En outre, il supprime votre capacité à avoir un contrôle granulaire sur l'accès. Si Alice doit écrire des chèques et qu'Eve doit les signer, vous n'avez essentiellement aucun moyen technologique de les appliquer s'ils partagent le même compte.
En outre, il est plus difficile pour une personne donnée de remarquer des changements malveillants dans son environnement. Alice sait quels fichiers se trouvent sur le bureau d'Alice. Tout nouveau fichier déclenchera 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 seront accueillis avec un haussement d'épaules et l'hypothèse qu'un autre utilisateur l'a mis là, pas un acteur malveillant.
Histoire réelle, survenue sur le lieu de travail d'un ami (juridiction: Allemagne):
Une collègue de ses clients grossièrement insultés via le courrier électronique 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 avaient partagé leurs mots de passe (par exemple, pour avoir répondu au courrier d’un client en l’absence d’un certain collègue).
Le juge a jugé qu'il n'y avait pas de bonne preuve que la personne en question était bien celle qui avait envoyé les courriels insultants. La personne a dû être réembauchée et indemnisée pour la perte de salaire.
Moral: Une fonction des comptes d'utilisateurs est de discerner les utilisateurs les uns des autres, de 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 d'Adonalsium vous montre que c'est obligatoire. Il existe de rares situations où ce n'est "pas possible" ou "pas utile" ...
Exemples: "pas possible" (protocoles/applications hérités) "pas pertinent" (actions anonymes)
Si ce n'est pas possible, mais que vous devez vous identifier, vous devez atténuer le risque d'ajouter autant d'informations sources que possible (par exemple, les informations de connexion, le temps de connexion, etc.)
Vous pouvez vérifier 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 d'utilisateurs partagés?"
La réponse typique est la responsabilité, la traçabilité, etc. En d'autres termes, pouvoir savoir exactement qui a fait quoi.
Un compte partagé a n personnes potentielles faisant quelque chose mais tout ce que vous avez indique qu'un 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 réalisable ou non, et il se peut que personne ne prenne la responsabilité des actions des autres.
Ce problème se produit souvent lorsque vous externalisez certaines activités de surveillance - le compte qui effectue les tâches de surveillance doit être contractuellement responsable de cette entreprise, qui est responsable de ses actions.
Si vous ne pouvez pas affecter une personne responsable, c'est à la direction de prendre une décision en fonction du risque: ne pas avoir de service ou ne pas 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 des choses que la plupart des gens pensent être la meilleure façon.
Cela va dans l'autre sens. Une fois qu'une "meilleure pratique" est dominante, généralement un membre d'un comité de normalisation décide de la mettre dans une norme ISO ou autre. Il repose ensuite là, généralement sans raisonnement explicite, ou un raisonnement circulaire soulignant qu'il s'agit de la meilleure pratique.
Les raisons de cette pratique particulière sont également pratiques. Si Alice et Bob partagent un compte et que quelque chose de grave 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étendent que cela a été compromis, mais vous avez au moins un seul point à approfondir.
Il existe également des exigences explicites en matière de responsabilité dans de nombreux sous-domaines tels que la conformité, et elles y jouent un rôle.
Je ne connais qu'une exception à cette règle. Il existe une seule machine partagée par plusieurs utilisateurs, et les affirmations suivantes sont toutes vraies:
Cela peut se produire sur des systèmes 7/7 24/24. Dans ce cas d'utilisation, vous conservez toujours une imputabilité acceptable en connaissant l'utilisateur qui était présent à un moment spécifique, à condition que vous puissiez définir la deuxième règle ci-dessus. Mais en fait, c'est équivalent d'avoir un compte sans mot de passe et de n'utiliser que la sécurité physique.
Un autre problème non encore 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 accède pas/n'y accède pas et ne s'attend pas à ce que quelqu'un d'autre le fasse, il ' Il est beaucoup plus probable qu'ils sonnent l'alarme qu'ils ne le seraient s'ils pensaient que le compte aurait pu être consulté par quelqu'un qu'ils avaient autorisé.
Étant donné le nombre de cas où il peut être nécessaire qu'une personne autorise une autre personne à 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 meilleure compréhension et un examen rapide.
Responsabilité
La responsabilité est un autre principe important de la sécurité de l'information qui fait référence à la possibilité de retracer les actions et les événements dans le temps jusqu'aux utilisateurs, aux systèmes ou aux processus qui les ont exécutés, afin d'établir la responsabilité des actions ou des omissions.
Conformité
Si vous vous dirigez vers 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 qui ont été compromis ou qui étaient 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 respectez aucune réglementation, vous devriez toujours (recommandé) suivre les "meilleures pratiques", cela aide votre processus réseau global à grande échelle.
En plus du problème d'audit que d'autres réponses soulignent, les comptes d'utilisateurs partagés sont intrinsèquement moins sécurisés qu'un compte d'utilisateur unique sur la même plate-forme.
Si plus 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 dit le proverbe, deux peuvent garder un secret si l'un est mort.
Je voudrais également mettre 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 par nature le partage de la gloire du blâme. Vous pourriez décourager la responsabilité personnelle et l'éthique du 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 l'effort supplémentaire lorsqu'une autre personne va de toute façon faire la mauvaise chose?
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 gênant. Vous vous retrouveriez probablement avec le plus petit dénominateur commun pour la faiblesse des mots de passe (CompanyName01
?) ou un mot de passe physiquement écrit pour tous dans la zone à voir.
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:
root
sur Unix/Linux. Oui, vous imposerez de nombreuses restrictions sur l'utilisation de root
en production, comme Sudo
avec une journalisation et une surveillance de la sécurité étendues, un coffre-fort de mots de passe, etc., mais il s'agit toujours d'un compte partagé .