Mauvaise pratique pour avoir un mot de passe "dieu"?
Est-ce une mauvaise pratique de sécurité d'avoir un mot de passe qui vous permettra d'accéder à n'importe quel compte d'utilisateur sur un site Web à des fins d'assistance? Le mot de passe serait stocké de manière sécurisée et serait super complexe. Grosse erreur?
Cela ressemble beaucoup à un compte "Administrateur", qui autrement a généralement un accès illimité aux choses dont il est l'administrateur.
Les implications en matière de sécurité d'un compte administrateur sont assez bien comprises, tout comme les meilleures pratiques. Je n'entrerai pas dans tous les détails, mais votre mise en œuvre rompt avec les meilleures pratiques sur une caractéristique clé: la traçabilité.
Vous voulez pouvoir dire qui a fait quoi, en particulier en ce qui concerne les administrateurs. Si un administrateur peut se connecter à mon compte en utilisant son mot de passe, il n'y a aucun moyen pour un vérificateur après coup de déterminer ce qui a été fait par moi par rapport à ce qui a été fait par l'administrateur.
Mais si à la place l'administrateur se connecte à son propre compte avec son mot de passe super-sécurisé, alors grâce à l'accès qu'il a via son propre compte effectue une action que j'aurais pu faire également - eh bien maintenant nous pouvons avoir un journal indiquant qui l'a fait quoi. C'est assez important lorsque le fumier frappe le ventilateur. Et encore plus lorsque l'un des comptes d'administrateur est compromis (ce qu'il sera , malgré tous vos efforts).
Supposons également que l'entreprise se développe et que vous ayez besoin de 2 administrateurs. Partagent-ils le mot de passe super génial? NON NON NON. Ils ont tous deux leurs propres comptes d'administrateur, avec un suivi et une journalisation séparés et tout cela. Vous pouvez maintenant dire QUEL administrateur a fait quoi. Et, plus important encore, vous pouvez fermer l'un des comptes lorsque vous licenciez l'un des administrateurs pour avoir volé les beignets.
Il y a beaucoup de bonnes informations dans les réponses données jusqu'à présent que l'affiche originale doit lire et prendre à cœur. Cependant, je pense que la plupart des réponses ne reflètent pas l'esprit de la question en ce qui concerne la traversée du site Web de leur entreprise "comme s'ils étaient l'utilisateur" à des fins d'assistance. Le cœur de la question semble être que cette activité se produit sur le front-end d'un site Web plutôt que sur la console d'un serveur.
Je connais une entreprise qui a le même besoin dans son application Web et l'a déjà résolu d'une manière qui, je crois, est le type de solution que l'affiche originale recherchait.
Ils ont créé un système de "mascarade" dans leur application Web qui permet à un employé d'un groupe spécial d'entrer un ensemble de pages pouvant rechercher n'importe quel utilisateur du système et de sélectionner cet utilisateur comme informations d'identification pour parcourir le système. Il suit l'utilisateur sélectionné pour se faire passer pour et l'utilisateur réel de l'employé comme deux entités distinctes et simultanées qui sont à la fois enregistrées à tout moment et pour chaque action.
Du point de vue de l'application, il s'agit de "me traiter comme cet utilisateur, mais n'oubliez pas que je suis en fait cet autre utilisateur". Une sorte de version webapp de Sudo, mais intégrée au front-end.
Cette méthode:
- Élimine le cauchemar de la piste d'audit, car les deux comptes d'utilisateurs sont toujours suivis.
- Fournit aux employés une "vue utilisateur" exacte des pages.
- Conserve les informations d'identification individuelles pour les employés afin qu'il n'y ait pas de mot de passe partagé ou "maître".
- Maintient la sécurité des utilisateurs, dont les mots de passe ne sont jamais disponibles pour les employés.
- Conserve la solution au niveau de la couche application, sur le site Web, afin que n'importe qui puisse le faire sans accès ni connaissances au niveau des systèmes.
- L'employé peut également "démasquer" à tout moment et comparer le contenu des pages avec son propre compte ou d'autres comptes d'utilisateurs, ce qui est très utile pour déterminer si les bogues sont globaux ou spécifiques à l'utilisateur.
Oui, c'est une erreur. Que se passe-t-il si l'attaquant parvient à obtenir ce mot de passe, quelle que soit la sécurité que vous pensez qu'il est? Il sera en mesure de falsifier les informations de compte d'utilisateur d'une manière qui est très probablement difficile à différencier de l'activité normale.
Si vous contrôlez le site Web, vous disposez déjà de nombreuses méthodes différentes pour l'option d'assistance. Des outils d'administration appropriés peuvent être écrits pour lire et modifier les informations nécessaires. Il est inutile d'avoir un mot de passe "maître".
Ce mot de passe "dieu" est l'équivalent de l'accès root/administrateur: peut tout faire. La question est double:
Est-ce une bonne idée d'avoir une sorte d'accès du type "peut tout faire"? En pratique, c'est plus "inévitable" que "bon", mais oui, c'est normal. Assurez-vous cependant d'avoir des procédures d'utilisation appropriées: vous ne voulez pas que les administrateurs fassent l'administration à partir d'une machine partagée dans un café; et vous voulez savoir "qui ne sait pas". En ce sens, lorsqu'il y a deux personnes ou plus dotées de privilèges d'administrateur, il est préférable qu'elles agissent "comme elles-mêmes" en tant que membres d'un groupe d'administrateurs (dans le monde Unix, utilisez
Sudopour que les commandes soient enregistrées).Est-ce une bonne idée de faire en sorte que les administrateurs exercent leurs privilèges via l'API utilisateur normale ? Celui-ci est discutable. Autoriser un "mot de passe divin" signifie installer l '"exception divin" dans votre application, ce qui risque d'être abusé. Il augmente la complexité du système d'authentification + autorisation dans votre site, et la complexité est la seule chose que vous souhaitez éviter en matière de sécurité. Les bogues se développent dans la complexité. Un "mot de passe divin" peut être pratique pendant le développement, mais, d'une manière générale, il a tendance à augmenter la probabilité d'une faille de sécurité dévastatrice, donc utilisez-le avec une extrême prudence.
Bien sûr, le contexte est tout, et les réponses ci-dessus simplement s'appliquent généralement . Méfiez-vous néanmoins des portes dérobées administratives, en particulier des portes dérobées qui ne gardent pas un bon historique de l'origine des demandes administratives.
Un administrateur ne peut toujours agir que lui-même: une personne avec un mot de passe divin peut se faire passer pour n'importe qui sur le système. On pourrait faire valoir que si l'administrateur a suffisamment de pouvoir, cela ne fait pas grand-chose pour limiter les dégâts réels qu'un attaquant avec ce compte pourrait faire. Mais un attaquant avec le mot de passe divin aurait beaucoup plus de facilité à couvrir ses traces.
Avoir un mot de passe "dieu" est une solution simple, mais c'est simplement une "autorisation" par la connaissance du mot de passe maître, et ne se prête pas à une bonne gestion des accès (c'est-à-dire contrôler qui peut le faire), ni à la responsabilité (qui vraiment fait quoi).
Au lieu de cela, modifiez la structure de vos données d'identification pour avoir un champ utilisateur effectif:
{
user: alice,
effective_user: bob,
}
Le contenu de vos pages Web doit être rendu pour le effective_user, sauf s'il s'agit d'une page administrative interne qui a besoin de savoir qui vraiment navigue. Notez que la plupart des personnes externes parcourant votre site auront toujours le même identifiant pour les deux champs:
{
user: alice,
effective_user: alice,
}
Cet arrangement vous permet de mieux contrôler qui est autorisé à devenir un autre utilisateur, et il vous permet également d'enregistrer/vérifier qui a fait quoi au nom de qui. (Vous pouvez simplement connecter à la fois l'utilisateur et effective_user sur les choses que vous souhaitez surveiller.) Unix fait ce genre de chose efficace pour l'utilisateur (et le groupe) en interne si vous regardez les sources pour définir ce qui définit un processus. L'imiter sur le Web s'appuie sur un paradigme connu et réussi.
Cette solution vous permet également de choisir les pages que votre personnel peut "regarder par-dessus l'épaule" d'un autre utilisateur. Vous pouvez choisir d'écrire une page qui ne s'affiche pas sur la base du effective_user, aucune de ces pages ne peut être vue par votre personnel, même s'il a le privilège de modifier son identifiant utilisateur effectif.
BTW, j'ai implémenté le concept d'utilisateur efficace sur le web, et j'ai également implémenté le mot de passe divin. Ce dernier est facile à installer lorsque toute l'infrastructure est déjà en place. Mais ce n'est vraiment pas la meilleure solution en termes de savoir qui a fait quoi et de gérer l'accès. Examinez de près la quantité de refactoring réellement impliquée pour ajouter le champ utilisateur efficace - il peut être inférieur à ce que vous pensez.
Vous ne vous faites jamais passer pour l'utilisateur. (Pour diverses raisons de traçabilité/responsabilité comme d'autres déjà mentionnées.)
Au lieu de cela, vous voyez une copie de l'écran de l'écran des utilisateurs comme si vous vous teniez derrière eux en regardant par-dessus leur épaule.
C'est à cela que servent les outils de partage d'écran/bureau comme VNC, TeamViewer, l'assistance à distance, etc.
Si une seule personne a accès, ce n'est pas nécessairement un problème, mais cela peut tout aussi facilement être fait en ayant un paramètre pour un compte d'utilisateur qui autorise cet accès.
Avec tout type de fonctionnalité root/superutilisateur/admin, la journalisation et l'audit du comportement sont essentiels, et cela signifie que vous devez savoir qui faisait quoi. Si plusieurs utilisateurs doivent pouvoir apporter des modifications comme celle-ci, ce doit être un indicateur sur leur compte pour le permettre.
Vous pouvez toujours vouloir avoir un mot de passe supplémentaire, plus compliqué qui doit être entré même lorsqu'ils y ont accès, mais vous devez exiger l'authentification sécurisée d'une personne qui apporte des modifications avant de faire quoi que ce soit de cette nature.
Je pense que vous devez avoir une sécurité basée sur les rôles plutôt qu'un seul compte avec des capacités en mode "dieu". De cette façon, vous pouvez avoir plusieurs personnes qui ont les mêmes rôles avec des capacités similaires, de sorte que si votre dieu/administrateur n'est pas disponible, quelqu'un d'autre peut apporter une correction.
Je sais que cela est préférable surtout si vous allez être audité.
Vous n'avez peut-être pas d'autre choix que d'avoir un mot de passe "dieu". Indépendamment de ce que tylerl a dit à propos de deux mots de passe administrateur différents, comment serait-il même possible d'avoir un journal et un suivi à moins que quelqu'un ne soit également en charge? Vous devrez littéralement crypter le journal et tout ce qui vous concerne de telle manière qu'il ne soit lu que par le monde extérieur mais puisse toujours écrire pour lui-même. Comment détermine-t-il alors si les informations qu'il reçoit sont légitimes ou non? Évidemment, si vous n'y avez pas accès, personne ne le fait, cela ne fonctionnerait pas non plus.