> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/fr/user-group-based-access-control/scenarios/simplified-security.md). # Sécurité simplifiée {% hint style="info" %} Cette fonctionnalité est uniquement disponible lors de l'utilisation d'un [espace de travail avancé](/rdm/fr/getting-started/workspaces/workspace-types/native-workspaces.md). {% endhint %} {% hint style="warning" %} Bien que le scénario suivant soit pertinent pour les petites et moyennes entreprises, il n'est pas recommandé pour une plus grande entreprise. Pour un scénario mieux adapté aux grandes entreprises, veuillez consulter le scénario [Sécurité avancée](/rdm/fr/user-group-based-access-control/scenarios/advanced-security.md). {% endhint %} Notre entreprise fictive, Windjammer, compte quatre groupes d'utilisateurs : HelpDesk, ServiceDesk, Administrations et Consultants. Il y a deux entreprises clientes : Downhill Pro et Telemark. La structure arborescente suivante représente les entrées auxquelles les utilisateurs ont accès une fois toutes les permissions définies : ![](https://cdnweb.devolutions.net/docs/docs_en_rdm_windows_RDMWin6055.png) #### Configuration des utilisateurs Voici un exemple de configuration des utilisateurs. Pour créer des utilisateurs, naviguez vers ***Administration – Utilisateurs – Ajouter un utilisateur***. La sélection de droits suivante est disponible lorsqu'un utilisateur est défini comme ***Utilisateur restreint***.
***Administrateurs*** : les administrateurs ont beaucoup plus d'accès que les utilisateurs réguliers. Lors de la création de ces utilisateurs, définissez le type d'utilisateur à ***Administrateur*** pour leur donner accès à tout. L'administrateur peut accéder à toutes les entrées, quelles que soient les permissions.
***Utilisateurs réguliers (Utilisateur)*** : ces utilisateurs ont moins de droits que les administrateurs. Ils ont essentiellement tous les droits de base (sauf ***Voir le mot de passe***), mais sont assujettis à toutes les permissions refusées. Plus tard, nous refuserons ces droits en précisant quels utilisateurs peuvent réellement effectuer ces actions. ***Consultants*** : les consultants ne peuvent voir qu'un sous-ensemble d'entrées, nous les définirons donc comme ***Lecture seule***. Ils ne peuvent pas ajouter, modifier ou affecter l'information de quelque manière que ce soit. #### Configuration des groupes d'utilisateurs Maintenant que les utilisateurs sont créés, nous ajouterons les groupes d'utilisateurs auxquels nous accorderons plus tard les permissions. Nous devons créer les groupes d'utilisateurs pour y assigner des utilisateurs. Il n'est pas nécessaire d'accorder des privilèges à ces groupes d'utilisateurs. * ServiceDesk * HelpDesk * Consultants
#### Configuration des entrées Maintenant, tout est prêt pour accorder ou refuser l'accès aux groupes d'utilisateurs. * Le ServiceDesk aura la permission de voir et d'ouvrir toutes les entrées, mais pourra modifier uniquement les entrées dans les groupes/dossiers des clients. * Le HelpDesk aura la permission de voir et d'ouvrir les entrées dans les groupes/dossiers des clients seulement et ne pourra pas les modifier. * Les Consultants auront la permission de voir et d'ouvrir les entrées dans le dossier Montreal seulement, mais ne pourront pas le modifier ni ses éléments enfants. Nous commencerons par les dossiers au niveau du coffre : Downhill Pro, Telemark et Windjammer. La permission de voir le dossier Windjammer sera définie pour le ServiceDesk seulement, puisque nous voulons qu'il puisse utiliser ses entrées enfants. Nous ne voulons pas que le ServiceDesk ajoute ou modifie quoi que ce soit. Nous définirons les permissions ***Ajouter***, ***Modifier*** et ***Supprimer*** à ***Jamais***. Seul l'administrateur pourra ajouter ou modifier des entrées dans le dossier Windjammer.
* ***Voir : Personnalisé***; ServiceDesk. * ***Ajouter : Jamais***; seul l'administrateur peut ajouter des entrées. * ***Modifier : Jamais***; seul l'administrateur peut modifier des entrées. * ***Supprimer : Jamais***; seul l'administrateur peut supprimer des entrées. * ***Déplacer : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent déplacer des entrées. * ***Voir le mot de passe : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir le mot de passe. * ***Voir l'information sensible : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir l'information sensible. Pour Downhill Pro, nous accorderons des permissions au ServiceDesk et au HelpDesk.
* ***Voir : Personnalisé***; HelpDesk, ServiceDesk. * ***Ajouter : Personnalisé***; ServiceDesk. * ***Modifier : Personnalisé***; ServiceDesk. * ***Supprimer : Jamais***; seul l'administrateur peut supprimer des entrées. * ***Déplacer : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent déplacer des entrées. * ***Voir le mot de passe : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir le mot de passe. * ***Voir l'information sensible : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir l'information sensible. Nous avons déjà un bon exemple de la flexibilité de la sécurité de Remote Desktop Manager. Un utilisateur du ServiceDesk peut voir et utiliser toutes les entrées du dossier Downhill Pro, même les entrées d'identifiants, mais il ne pourra jamais voir aucun mot de passe puisque Voir le mot de passe est Refusé (à partir du dossier du coffre). Ensuite, pour le dossier Telemark, nous accorderons des permissions au ServiceDesk, au HelpDesk et aux Consultants. C'est ici que les choses se complexifient. Si nous voulons que les Consultants puissent voir uniquement le dossier Montreal, qui est un élément enfant de Telemark, nous devons accorder aux consultants la permission de voir tout le contenu de Telemark. Ensuite, nous accorderons des permissions sur les éléments enfants uniquement au groupe d'utilisateurs qui devrait avoir accès à ces éléments. Cette dernière étape refusera la permission de voir aux consultants sur les éléments enfants.
* ***Voir : Personnalisé***; Consultants, HelpDesk, ServiceDesk. * ***Ajouter : Personnalisé***; ServiceDesk. * ***Modifier : Personnalisé***; ServiceDesk. * ***Supprimer : Jamais***; seul l'administrateur peut supprimer des entrées. * ***Déplacer : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent déplacer des entrées. * ***Voir le mot de passe : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir le mot de passe. * ***Voir l'information sensible : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir l'information sensible. Puisque nous voulons que les utilisateurs puissent utiliser les entrées d'identifiants, nous accorderons au ServiceDesk et au HelpDesk la permission de voir le dossier Credentials. De cette façon, le ServiceDesk et le HelpDesk pourront utiliser les entrées du dossier sans révéler les mots de passe. Ainsi, en précisant que seuls le HelpDesk et le ServiceDesk ont la permission ***Voir***, nous refusons l'accès en visualisation à tout groupe d'utilisateurs ou utilisateur qui n'est pas dans la liste de la permission. Les permissions ***Ajouter***, ***Modifier*** et ***Supprimer*** peuvent être laissées à ***Hérité*** puisqu'elles héritent des paramètres du dossier parent Telemark. Le ServiceDesk est le seul groupe d'utilisateurs à qui les permissions ***Ajouter*** et ***Modifier*** ont été accordées dans le dossier parent et la permission ***Supprimer*** hérite du paramètre Jamais.
* ***Voir : Personnalisé***; HelpDesk, ServiceDesk. * ***Ajouter : Hérité***; ServiceDesk hérité du dossier Telemark. * ***Modifier : Hérité***; ServiceDesk hérité du dossier Telemark. * ***Supprimer : Hérité***; Jamais hérité du dossier Telemark. * ***Déplacer : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent déplacer des entrées. * ***Voir le mot de passe : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir le mot de passe. * ***Voir l'information sensible : Hérité***; Jamais hérité du coffre. Seuls les administrateurs peuvent voir l'information sensible. Nous voulons que le ServiceDesk puisse également utiliser l'entrée d'identifiants Domain Admin, mais pas le HelpDesk. Pour ce faire, nous devons accorder la permission ***Voir*** au ServiceDesk. Le ServiceDesk pourra toujours modifier l'entrée d'identifiants, mais ne verra jamais le mot de passe. La permission de supprimer est définie à ***Jamais***.
La dernière étape pour les éléments enfants de Telemark est de définir la permission ***Voir*** pour le ServiceDesk et le HelpDesk sur le dossier Boston et de laisser toutes les autres permissions de ce dossier à ***Hérité***. Cela refuse aux Consultants de voir le dossier Boston. Maintenant, les Consultants pourront voir et ouvrir les entrées uniquement dans le dossier Montreal.
{% hint style="warning" %} Chaque fois qu'un nouveau dossier est ajouté, la permission ***Voir*** doit être définie pour le ServiceDesk et le HelpDesk afin de masquer le nouveau dossier et son contenu aux Consultants. {% endhint %} Il n'est pas nécessaire de définir des permissions sur le dossier Montreal, puisqu'elles sont héritées des dossiers parents.
#### En conclusion Les permissions sont maintenant correctement définies. Notez que chaque entrée ajoutée au niveau du coffre n'aura aucune sécurité par défaut. Cela signifie qu'elles seraient disponibles pour tout le monde, même les consultants. Cela peut être confirmé en regardant la capture d'écran ci-dessous dans laquelle l'entrée ***Daily routine*** est disponible pour tout le monde. Voici ce que chaque utilisateur devrait voir dans la vue arborescente :
Vous pouvez personnaliser davantage vos permissions en utilisant l'onglet ***Paramètres de sécurité*** lors de la modification des entrées, ou l'onglet ***Journaux*** pour ajouter plus de traces des allées et venues. Comme toujours, il faut faire preuve d'une grande prudence lors de l'octroi de permissions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/rdm/fr/user-group-based-access-control/scenarios/simplified-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.