Cela ressemble beaucoup à un compte "Administrateur", qui a généralement un accès illimité aux éléments dont il est l'administrateur.

Les implications de sécurité d'un compte administrateur sont assez bien comprises, comme sont 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 être en mesure de dire qui a fait quoi, en particulier pour les administrateurs. Si un administrateur peut se connecter à mon compte en utilisant son mot de passe, il n'y a aucun moyen pour un auditeur 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é, puis grâce à l'accès qu'il a via son propre compte effectue une action que j'aurais pu faire aussi - eh bien maintenant, nous pouvons avoir un journal indiquant qui a fait quoi. C'est assez important lorsque le fumier frappe le ventilateur. Et encore plus lorsqu'un des comptes d'administrateur est compromis (ce qui le fera , malgré tous vos efforts).

De plus, disons que l'entreprise se développe et que vous avez besoin de 2 administrateurs. Partagent-ils le mot de passe génial? NON NON NON. Ils ont tous deux leurs propres comptes d'administrateur, avec un traçage 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 renvoyez l'un des administrateurs pour avoir volé les beignets.

Il y a beaucoup d'informations intéressantes dans les réponses données jusqu'à présent que l'affiche originale devrait 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 navigation sur le site Web de leur entreprise "comme si elles é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 ce même besoin dans son application Web et l'a déjà résolu d'une manière qui, je pense, est le genre 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 de saisir un ensemble de pages pouvant rechercher n'importe quel utilisateur dans le système et de sélectionner cet utilisateur comme informations d'identification pour parcourir le système avec. Il suit l'utilisateur sélectionné pour se faire passer pour et l'utilisateur employé réel comme deux entités distinctes et simultanées qui sont toutes deux enregistrées à tout moment et pour chaque action.

Du point de vue de l'application, c'est un "traitez-moi comme cet utilisateur, mais rappelez-vous 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:

1. Élimine le cauchemar de la piste d'audit, car les deux comptes utilisateurs sont toujours suivis.
2. Fournit aux employés une «vue utilisateur» exacte des pages.
3. Conserve les informations d'identification individuelles des employés afin qu'il n'y ait pas de mot de passe partagé ou "maître".
4. Assure la sécurité des utilisateurs, dont les mots de passe ne sont jamais disponibles pour les employés.
5. Maintient la solution au niveau de l'application, sur le site Web, afin que tout le monde puisse le faire sans accès ni connaissance au niveau des systèmes.
6. L'employé peut également «démasquer» à tout moment et vérifier le contenu de la page par rapport à leur 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 un attaquant parvient à obtenir ce mot de passe, quelle que soit la sécurité que vous pensez qu'il est? Il pourra falsifier les informations du compte utilisateur d'une manière qui est 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 administratifs appropriés peuvent être écrits pour lire et modifier les informations nécessaires. Il ne sert à rien d'avoir un mot de passe «maître».

Ce mot de passe "god" est l'équivalent d'un accès root / administrateur: peut tout faire. La question est double:

1. Est-ce une bonne idée d'avoir une sorte d'accès du type «peut tout faire»? En pratique, c'est plus «incontournable» que «bien», mais oui, c'est une chose normale. Assurez-vous cependant d'avoir des procédures d'utilisation appropriées: vous ne voulez pas que les administrateurs effectuent l'administration à partir d'une machine partagée dans un café; et vous voulez savoir "qui dunn'it". 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 administrateur (dans le monde Unix, utilisez sudo pour que les commandes soient consignées).

2. Est-ce une bonne idée de demander aux administrateurs d'exercer leurs privilèges via l'API utilisateur normale ? Celui-ci est discutable. Autoriser un «mot de passe de Dieu» signifie installer «l'exception de Dieu» dans toute votre application, ce qui risque de faire l'objet d'abus. Cela augmente la complexité du système d'authentification + d'autorisation dans votre site, et la complexité est la seule chose que vous voulez éviter en matière de sécurité. Les bogues prospèrent dans la complexité. Un "mot de passe divin" peut être pratique pendant le développement, mais, de manière générale, il a tendance à augmenter la probabilité d'une faille de sécurité dévastatrice, alors utilisez-le avec une extrême prudence.

Of Bien sûr, le contexte est tout, et les réponses ci-dessus s'appliquent simplement généralement . Cependant, méfiez-vous des portes dérobées administratives, en particulier des portes dérobées qui ne conservent pas une bonne trace de l'origine des demandes administratives.

Un administrateur ne peut agir qu'en tant que lui-même: quelqu'un avec un mot de passe divin peut se faire passer pour n'importe qui sur le système. On pourrait affirmer que si l'administrateur a suffisamment de puissance, 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 il s'agit simplement d'une "autorisation" par le biais de la connaissance du mot de passe principal, 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 a vraiment fait quoi).

Au lieu de cela, modifiez la structure de données de vos identifiants pour avoir un champ d'utilisateur effectif:

  {user: alice, effective_user: bob,}  

Le contenu de vos pages Web doit être rendu pour effective_user , sauf s'il s'agit d'une page administrative interne qui a besoin de savoir qui est vraiment navigation. Notez que la plupart des personnes externes qui naviguent sur votre site auront toujours le même identifiant pour les deux champs:

  {user: alice, effective_user: alice,}  

Ceci L'arrangement vous permet de mieux contrôler qui est autorisé à devenir un autre utilisateur, et il vous permet également d'enregistrer / de 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 d'utilisateur (et de groupe) efficace en interne si vous regardez les sources pour ce qui définit un processus. Imiter cela 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 en fonction de l ' utilisateur_effectif , alors aucune de cette page ne peut être vue par votre personnel même s'ils ont le privilège de modifier leur identifiant d'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 à mettre en place lorsque toutes les infrastructures sont déjà en place. Mais ce n'est vraiment pas la meilleure solution pour savoir qui a fait quoi et gérer l'accès. Regardez de près à quel point le refactoring est vraiment impliqué pour ajouter le champ utilisateur efficace - il peut être moins que vous ne le pensez.

Vous ne vous faites jamais passer pour l'utilisateur. (Pour diverses raisons de traçabilité / responsabilité, comme d'autres l'ont déjà mentionné.)
À la place, vous visualisez une copie de l'écran des utilisateurs comme si vous vous teniez derrière eux en regardant par-dessus leur épaule.
C'est quel écran / Les outils de partage de bureau comme VNC, TeamViewer, l'assistance à distance, etc. sont pour.

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 utilisateur qui autorise cet accès.

Avec n'importe quel root Le type de fonctionnalité / superuser / 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, il devrait y avoir un indicateur sur leur compte pour les autoriser.

Vous voudrez peut-être toujours avoir un mot de passe supplémentaire, plus compliqué saisis même lorsqu'ils y ont accès, mais vous devez exiger une authentification sécurisée d'une personne qui apporte des modifications avant de faire quoi que ce soit de cette nature.

Vous n'avez peut-être pas d'autre choix que d'avoir un mot de passe «divin». Indépendamment de ce que Tylerl a dit sur le fait d'avoir deux mots de passe d'administrateur différents, comment serait-il même possible d'avoir un journal et un traçage à moins que quelqu'un ne soit également responsable de cela? Vous auriez littéralement à crypter le journal et tout contre vous-même de manière à ce qu'il ne soit lu que par le monde extérieur mais puisse toujours écrire pour lui-même. Comment détermine-t-il 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.

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 puisse faire le correctif.

Je sais que c'est particulièrement préféré si vous allez être audité.