Comportement des champs personnalisés cachés

... d'autant plus que lorsqu'on consulte les champs personnalisés (sous forme de tableau), il y a une clé dans le champ nom et son tooltip indique "Requiert la permission < Voir le mot de passe >".

Ceci vient renforcer ma théorie qu'il s'agit bel et bien d'un bug...

Merci!

Bonjour,

Vous avez effectivement trouvé un bug; je vous dirais même deux.

1. L'icône de la clé pour les mots de passe n'est pas censée être affichée sur les champs personnalisés. Elle semble être tout simplement affichée en permanence dans cette section même pour les champs de type texte.
2. L'interface pour saisir les champs personnalisés offre un bouton qui fait un effet secondaire. En fait, le bouton de cadenas fait deux actions.
   1. Il permet le visionnement ou la modification de la valeur.
   2. Il change le type de champ personnalisé de cacher à texte.

Les champs personnalisés ont deux types: texte et caché. Ces deux types ne sont pas considérés comme des mots de passe au niveau du système.

Merci, bonne journée!

Je ne vois pas de bouton cadenas lors de l'édition des champs personnalisés. Vous voulez parler du petit oeil à chaque champ?



Au point 2 de votre réponse précédente, vous voulez dire qu'on ne peut protéger des champs personnalisés des personnes qui n'ont pas le droit d'afficher les mots de passe?

Si c'est le cas, que me suggérez-vous pour les données sensibles? J'ai par exemple un identifiant Apple à consigner. Je peux utiliser le type Site Web pour inclure le url vers appleid.apple.com ou bien je peux utiliser le type Nom d'utilisateur / mot de passe. Dans les 2 cas, je dois consigner les 3 questions secrètes pour recouvrement de mon AppleID. Je croyais pouvoir utiliser les champs personnalisés à cet effet (ou bien suggestion: permettre 3 questions secrètes pour divers types d'entrées). Anyway, si ce n'est pas 3 questions secrètes il y a plusieurs situation où il faut rendre confidentiel certaines valeurs.

On constate qu'en règle générale, les divers types d'entrées de PHB ne semblent pouvoir cacher qu'une seule variable. SI notre raisonnement est exact, croyez-vous pouvoir permettre plusieurs données sensibles dans les types d'entrées?

En fait, j'ai la suggestion ultime ;-) Concocter un éditeur de types d'entrées où:

• On ajoute les variables que l'on veut, assigne les étiquettes pour ceux-ci.
• On détermine lesquels sont obligatoires ou non.
• On détermine lesquels nécessitent le droit "voir le mot de passe" pour les consulter.
• On peut regrouper certaines variables dans un onglet.
• Etc... Sky's the limit :-)

Ces designs pourraient même faire l'objet d'un repository commun chez Devolutions où un type d'entrée produit par un américain pourrait être downloadé par un européen. Devolutions pourraient même intégrer directement dans PHB les nouveaux types les plus populaires. Moi personnellement, je me ferais un type d'entrée AppleID par exemple car j'en ai plusieurs à consigner.

Qu'en pensez-vous?

Il y a tellement de potentiel dans ce produit... Lâchez-pas!

Bonjour,

Oui, désolé, dans RDM, le bouton change de l'oeil à un cadenas.



Pour votre suggestion, nous avons dans RDM les questions secrètes.



Cependant, celle-ci sont aussi visibles sans avoir la permission de voir les mots de passes. Cette section n'est pas visible dans le client Web de Hub.

L'idée d'avoir une entrée 100% modifiable fut déjà abordée dans le passé mais elle fut mise de côté. L'objectif principale de notre solution RDM est de visé l'intégration des technologies. Ce type d'entrée permet difficilement de faire des intégrations. Par contre, c'est vrai qu'elle résout les problèmes de conservation de l'information.

Pour être honnête, nous sommes en discussions à l'interne pour améliorer cette aspect de notre solution. (Attribuer plus de contrôle aux utilisateurs sur le visionnement des mots de passes et données sensibles.)

Merci, bonne journée!

Merci pour les clarifications.

Je comprends l'objectif de RDM mais je ne vous cacherai pas que de notre côté nous voulons utiliser PHB dans un rôle de voûte comme un LastPass, BitWarden de ce monde et c'est cette facette du produit qui est principalement véhiculée dans la promotion du produit. L'intégration avec RDM est une très bonne idée en soi mais je crois soupçonner que la structure interne est fortement liée.

C'est même assez évident que la fondation est RDM quand on crée une entrée dans PHB et qu'on va ensuite la consulter sous RDM pour constater la myriade de paramètres et valeurs disponibles... Cette intégration RDM "peut nuire" jusqu'à un certain niveau au développement de nouvelles fonctionnalités PHB.

On verra ce que vous nous réserverez dans l'avenir pour PHB et je suis certain, comme vous le dites, que vous analysez avec attention l'aspect de la gestion des données sensibles.

Merci!

Bonjour Yvéric,

Juste pour vous informer que nous avons créé
la tâche au développement, d'ajouter des champs spécifiques a des questions de
sécurité à l'entrée de type Website. Les réponses seront considérées sensibles.

Par le fait même il as été décidé d'ajouter une nouvelle permission d’accès aux
champs sensible. Ce qui permettra à nos différents clients de choisir ou non cette accès.
Merci encore pour toutes vos observations et demandes.

 
Bonne fin de journée

Wow! Merci France!

Vous êtes une équipe dynamique!

Svp, ne pas oublier de masquer également les réponses de questions de sécurité dans la section Données brutes de l'entrée.

Merci!

En fait, le contenu des champs personnalisés masqués peuvent être consultés en trichant via les données brutes... :-( Bug...

Encore moi :-)

Je constate que le mot de passe mnémonique devrait être "sensible" sinon on peut tricher.

Merci!

Bonjour,

Svp, ne pas oublier de masquer également les réponses de questions de sécurité dans la section Données brutes de l'entrée.

Oui, c'est fait dans notre environnement de test. Il s'agit de données sensibles, mais pas de mot de passe.

En fait, le contenu des champs personnalisés masqués peuvent être consultés en trichant via les données brutes... :-( Bug...

Les champs personnalisés sont de type "caché" et non sensible ni mot de passe. Donc, visible pour tous; tout simplement caché par défaut.

Je constate que le mot de passe mnémonique devrait être "sensible" sinon on peut tricher.

C'est une bonne observation, au niveau des données, il ne s'agit pas d'un champ sensible ni d'un mot de passe. De ce que j'ai eu comme commentaire, il s'agit d'un champ pour donner un indice pour le mot de passe, sans plus.

Pour être honnête, avec vos commentaires et l'amélioration que l'on envisage, je commence à songer à rendre les données brutes visibles qu'aux utilisateurs avec la permission à venir de "Voir les données sensibles". Qu'en pensez-vous?

Merci, bonne journée!

Re-bonjour,

Les champs personnalisés sont de type "caché" et non sensible ni mot de passe. Donc, visible pour tous; tout simplement caché par défaut.

Quel est l'objectif d'un champ caché s'il n'est pas sensible? Si tous peuvent l'afficher alors je m'interroge sur son utilité. Vous avez mon vote pour les changer pour "sensibles". ;-)

Mot de passe mnémonique: je m'en sert pour indiquer la passphrase servant à mémoriser le mot de passe. Exemple fictif: GLac1bdtb! Guy Lafleur a compté 1 but de toute beauté! (hé oui, je trahis mon âge quelque peu...) :-) La passphrase donne donc accès indirect au mot de passe.

Je ne crois pas que j'irais restreindre l'ensemble des données brutes à ceux ayant le rôle "voir les données sensibles" mais pour la simplicité d'implanter cette fonctionnalité c'est probablement l'orientation à suivre. Cependant, il faudrait que les mots de passe ne soient visibles que pour le rôle "voir les mots de passe". Il s'agit d'un cran plus fort que "voir les données sensibles" à mon avis (après une courte réflexion de 2 minutes haha).

Est-ce qu'un bouton "Exporter en XML" serait intéressant pour les données brutes? Je n'en ai pas besoin personnellement (je crois) mais pour certains autres de vos clients?

Bonne fin de journée!

Bonjour,

Quel est l'objectif d'un champ caché s'il n'est pas sensible? Si tous peuvent l'afficher alors je m'interroge sur son utilité. Vous avez mon vote pour les changer pour "sensibles". ;-)

Les champs cachés sont parfaits dans le contexte où il ne s'agit pas de valeurs sensibles pour vos utilisateurs / employés, mais qui sont sensibles pour les clients / acteurs externes. Par exemple, un technicien qui va chez un client qui doit laisser son ordinateur ouvert. Il y a possibilité qu'un client puisse regarder l'écran et que l'on ne veut pas qu'il voie directement les valeurs.

Mot de passe mnémonique: je m'en sert pour indiquer la passphrase servant à mémoriser le mot de passe. Exemple fictif: GLac1bdtb! Guy Lafleur a compté 1 but de toute beauté! (hé oui, je trahis mon âge quelque peu...) :-) La passphrase donne donc accès indirect au mot de passe.

Je dois avouer que c'est un peu trop direct; il s'agit du mot de passe littéralement. L'intention est vraiment qu'il s'agisse d'un aide mémoire. Ex: Le démon blond s'amuse ce soir!

Les données brutes sous format XML sont disponibles via RDM. Sinon, vous avez aussi le PowerShell pour obtenir les données au format JSON.

Bonne journée!

Merci pour les précisions Maxime!