Exploration des listes de contrôle d’accès

Explorez les listes de contrôle d’accès (ACL).

Composants des ACL

Toutes les règles de liste de contrôle d’accès spécifient :

• Objet et opération sécurisés
• Autorisations requises pour accéder à l’objet

L’objet est la cible dont l’accès doit être contrôlé. Chaque objet se compose d’un type et d’un nom qui identifient de manière unique une table, un champ ou un enregistrement particulier.

Par exemple, toutes ces entrées spécifient un objet :

Type	Nom	Objet sécurisé
record	[incident]. [--Aucun--]	La table Incident.
record	[incident]. [actif]	Champ Actif de la table Incident.
REST_Endpoint	user_role_inheritance	L’enregistrement de l’API REST scriptée user_role_inheritance.

Chaque opération décrit une action valide que le système peut effectuer sur l’objet spécifié. Certains objets, tels que les enregistrements, prennent en charge plusieurs opérations, tandis que d’autres, tels qu’un REST_Endpoint, ne prennent en charge qu’une seule opération.

Par exemple, toutes ces entrées spécifient une opération :

Type	Nom	Opération	Opération sécurisée
record	[incident]. [-- Aucun --]	créer	Création d’enregistrements dans la table Incident.
record	[incident]. [actif]	write	Mise à jour du champ Actif dans la table Incident.
REST_Endpoint	user_role_inheritance	execute	Exécution de l’API REST scriptée user_role_inheritance.

Les autorisations spécifient quand une personne peut accéder à l’objet et à l’opération nommés. Les administrateurs de sécurité peuvent spécifier les exigences en matière d’autorisation en ajoutant :

• Un ou plusieurs rôles d’utilisateur à la liste Rôles requis .
• Une ou plusieurs conditions.
• Script qui évalue sur vrai ou faux ou définit la variable de réponse sur vrai ou faux.

Pour accéder à un objet et à une opération, un utilisateur doit passer toutes les autorisations répertoriées dans un contrôle d’accès. Par exemple, ce contrôle d’accès restreint l’accès à l’affichage des opérations sur la table d’incidents.

Pour mettre à jour un enregistrement dans la table d’incidents, un utilisateur doit avoir les rôles répertoriés et l’enregistrement doit répondre à la condition.

Type d'autorisation	Besoin	Description
Demande un rôle	Demande role :itil	Autorisez uniquement les utilisateurs disposant du rôle ITIL à mettre à jour les incidents.
Condition	[État de l’incident] [n’est pas] [Fermé]	Autorisez uniquement les mises à jour des enregistrements d’incidents actifs.

Processus d’évaluation ACL

Une règle ACL accorde à un utilisateur l’accès à un objet uniquement si l’utilisateur répond à toutes les autorisations requises par la règle ACL correspondante.

• La condition doit être évaluée comme vraie.
• Le script doit donner la valeur true ou renvoyer une variable de réponse avec la valeur true.
• L’utilisateur doit avoir l’un des rôles de la liste des rôles requis. Si la liste est vide, cette condition est évaluée comme vraie.
• [Règles ACL d’enregistrement uniquement] Les règles ACL au niveau de la table et au niveau du champ correspondantes doivent toutes les deux avoir la valeur true.

Figure 1. ACL évaluer les autorisations

Chaque fois qu’une session demande des données, le système recherche des règles de contrôle d’accès qui correspondent à l’objet et à l’opération demandés. S’il existe une règle de contrôle d’accès correspondante, le système évalue si l’utilisateur dispose des autorisations requises pour accéder à l’objet et à l’opération. Si une règle de contrôle d’accès spécifie plusieurs autorisations, l’utilisateur doit disposer de toutes les autorisations pour accéder à l’objet et à l’opération. L’échec d’une vérification d’autorisation empêche l’utilisateur d’accéder à l’objet et à l’opération correspondants.

Si un utilisateur ne satisfait pas aux autorisations de la première règle de correspondance, le système évalue les autorisations de la règle de contrôle d’accès correspondante suivante, comme spécifié par l’ordre de traitement du contrôle d’accès. Si l’utilisateur ne répond pas aux autorisations d’une règle de contrôle d’accès correspondante, le système refuse l’accès à l’objet et à l’opération demandés.

Remarque :

S’il n’y a pas de règles de contrôle d’accès correspondantes pour l’objet et l’opération demandés, le système accorde l’accès à l’utilisateur. Dans la pratique, il est rare que le système ne trouve aucune règle de correspondance, car le système dispose d’un ensemble de règles de contrôle d’accès par défaut qui protègent toutes les opérations d’enregistrement.

Les conséquences d’un refus d’accès à un objet dépendent de la règle ACL selon laquelle l’utilisateur a échoué. Par exemple, l’échec d’une règle ACL d’opération de lecture empêche l’utilisateur de voir l’objet. Selon l’objet sécurisé, la règle ACL masque un champ sur un formulaire, masque des lignes d’une liste ou empêche un utilisateur d’accéder à une page de l’interface utilisateur. La table suivante contient une liste complète des résultats d’échec d’une règle ACL pour une opération et un type d’objet donnés.

Vérifications ACL avant et après requête

Votre instance vérifie les règles ACL avant et après qu’un utilisateur ait effectué une requête. Étant donné que des informations différentes sont disponibles avant et après une requête, les résultats peuvent être différents.

Vérification de l’ACL avant requête

Avant que votre instance n’exécute une requête de base de données, elle vérifie les règles ACL pour chaque champ de la table interrogée afin de déterminer les champs auxquels un utilisateur peut accéder. Cette vérification ne porte que sur les rôles de l’utilisateur et vérifie si ces rôles autorisent l’accès aux champs. Étant donné que cette vérification s’exécute avant la requête, l’ACL n’a pas accès aux enregistrements de la table et ne peut donc pas prendre ces données en compte. Les scripts et les conditions qui reposent sur la connaissance du contenu d’un enregistrement ne sont pas évalués.

Si l’utilisateur ne dispose pas d’un accès en lecture à ce stade, la valeur du champ ne lui est pas présentée.

Vérification de l’ACL après la requête

Après la requête, votre instance vérifie chaque enregistrement renvoyé par la requête. Au cours de cette vérification, il existe un contexte pour l’ACL, de sorte que les parties rôle, condition et script de l’ACL sont évaluées. Si l’utilisateur ne dispose pas d’un accès en lecture à ce stade, la valeur du champ ne lui est pas présentée, mais l’utilisateur voit l’étiquette du champ si ses rôles autorisent l’accès au champ.

Opération	Résultats de l’échec d’une règle ACL sur un objet
execute	L’utilisateur ne peut pas exécuter de scripts sur un enregistrement ou une page de l’interface utilisateur.
créer	L’utilisateur ne peut pas voir la nouvelle action d’interface utilisateur à partir des formulaires. L’utilisateur ne peut pas non plus insérer d’enregistrements dans une table à l’aide de protocoles API tels que les services Web. Une ACL de création avec une condition exigeant qu’un champ contienne une valeur spécifique est toujours évaluée comme fausse. Les champs des nouveaux enregistrements sont considérés comme vides jusqu’à ce que l’enregistrement soit enregistré.
lu	L’utilisateur ne peut pas voir l’objet dans les formulaires ou les listes. L’utilisateur ne peut pas non plus récupérer les enregistrements à l’aide de protocoles API tels que les services Web.
write	L’utilisateur voit un champ en lecture seule dans les formulaires et les listes, et l’utilisateur ne peut pas mettre à jour les enregistrements à l’aide de protocoles API tels que les services Web.
supprimer	L’utilisateur ne peut pas voir l’action d’interface utilisateur Supprimer des formulaires. L’utilisateur ne peut pas non plus supprimer des enregistrements d’une table à l’aide de protocoles API tels que les services Web.
edit_task_relations	L’utilisateur ne peut pas définir de relations entre les tables de tâches.
edit_ci_relations	L’utilisateur ne peut pas définir de relations entre les tables d’éléments de configuration [cmdb_ci].
save_as_template	Utilisé pour contrôler les champs qui doivent être enregistrés lors de la création d’un modèle.
add_to_list	L’utilisateur ne peut pas afficher ni personnaliser des colonnes spécifiques dans la mécanique de liste.
list_edit	L’utilisateur ne peut pas mettre à jour les enregistrements (lignes) d’une liste.
report_on	L’utilisateur ne peut pas créer de rapport sur la table ACL. Pour plus d’informations, consultez Restreindre la création de rapports avec une règle ACL.
report_view	L’utilisateur ne peut pas afficher le contenu d’un rapport sur la table ACL ou sur le champ ACL. Pour plus d'informations, consultez Reporting.
personalize_choices	L’utilisateur ne peut pas cliquer avec le bouton droit sur un champ de liste et sélectionner Configurer les choix.

Besoins de correspondance ACL pour les objets

Type d'objet	Règles ACL correspondantes requises pour accéder à l’objet	Règles ACL génériques existantes
Includes de script pouvant être appelés par le client	Les utilisateurs doivent disposer des autorisations de deux règles ACL : Toutes les règles ACL génériques pour l’objet (s’il existe une règle ACL pour l’opération). Première règle ACL correspondant au nom de l’objet (s’il existe une règle ACL pour l’opération).	Par défaut, il n’existe pas de règles génériques (*) pour ces types d’objets. Si vous créez une règle ACL générique pour l’un de ces objets, la règle ACL s’applique à tous les objets de ce type.
Processeurs
Pages de l'interface utilisateur	Les utilisateurs doivent disposer des autorisations de deux règles ACL : Première règle ACL qui correspond au champ de l’enregistrement (s’il existe une règle ACL pour l’opération). Première règle ACL qui correspond à la table de l’enregistrement (s’il existe une règle ACL pour l’opération).	Par défaut, il existe des règles de table génériques (*) pour les opérations de création, de lecture, d’écriture et de suppression et des règles de champs génériques (*.*) pour les opérations de personalize_choices, de création et de save_as_template. Lorsque vous créez une table, créez des règles ACL pour la table, sauf si vous souhaitez utiliser les règles ACL génériques fournies.
Enregistrement

Remarque :

La propriété Comportement par défaut du gestionnaire de sécurité (glide.sm.default_mode) détermine si les utilisateurs peuvent accéder aux objets qui correspondent uniquement aux règles ACL de table à caractère générique. Lorsque cette propriété est définie sur Refuser l’accès, seuls les administrateurs peuvent accéder aux objets qui correspondent aux règles ACL de la table à caractère générique.

Remarque :

La règle ACL de champ générique (*.*) pour l’opération de création réutilise les mêmes autorisations que l’opération d’écriture. Cela signifie que les autorisations de création sont les mêmes que les autorisations d’écriture, sauf si vous définissez une règle ACL d’opération de création explicite.

Plusieurs règles ACL au même point dans l’ordre de traitement

Si au moins deux règles correspondent au même point de l’ordre de traitement, l’utilisateur doit transmettre l’une des autorisations de règles ACL pour accéder à l’objet. Par exemple, si vous créez deux règles ACL de champ pour incident.number, un utilisateur qui transmet une règle a accès au champ de nombre, que l’utilisateur ait échoué ou non à une autre règle ACL de champ au même point de l’ordre de traitement.

Rôle requis

Les utilisateurs administrateurs normaux peuvent afficher et déboguer les règles de contrôle d’accès. Toutefois, pour créer ou mettre à jour des règles de contrôle d’accès existantes, les administrateurs doivent élever les privilèges au rôle security_admin. Consultez les Élever à un rôle privilégié pour obtenir les instructions.

Règles ACL dans les applications incluses dans le périmètre

Vous pouvez créer des règles ACL pour les objets dans le même champ d’application que la règle ACL. Vous pouvez également créer des règles ACL pour les tables ayant au moins un champ qui se trouve dans le même champ d’application que la règle ACL.

Pour les tables qui sont dans un champ d’application différent de l’enregistrement de règle ACL, les types de règles sont limités.

• Vous pouvez créer une règle ACL pour n’importe quelle table, page d’interface utilisateur ou autre objet du même champ d’application que la règle ACL.
• Vous pouvez créer une ACL pour un champ qui est dans le même champ d’application que la règle ACL.
  • Si la table se trouve dans le même champ d’application, vous pouvez utiliser un script pour évaluer les autorisations.
  • Si la table se trouve dans un champ d’application différent, vous ne pouvez pas utiliser de script pour évaluer les autorisations.
• Vous ne pouvez pas créer ni modifier les règles d’ACL pour des objets qui se trouvent dans un périmètre différent de celui de l’application que vous avez sélectionnée dans le sélecteur d’application, y compris ajouter un rôle à un ACL dans un périmètre différent.
• Vous pouvez créer des règles de table génériques (*) uniquement dans le champ d’application global.
• Vous pouvez créer des règles de champ générique (*) uniquement pour les tables dans le même champ d’application que la règle ACL.