Explorer les listes de contrôle d’accès

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

Type de décision, type de règle et opération qui définissent l’ACL
Objet sécurisé
Conditions requises pour accéder à l’objet

Composants d’ACL

Le type de décision définit si les utilisateurs sont autorisés à accéder à l’objet si les conditions sont remplies ou s’il refuse l’accès à l’objet si les conditions ne sont pas remplies.


Type de décision	Description
Refuser, sauf si	Limitez l’accès à la ressource en refusant explicitement l’accès sauf si les conditions sont remplies. Consultez acl-denial-behavior.html#acl-denial-behavior__section_qnd_snl_zbc pour plus d'informations.
Autoriser si	Autorisez l’accès à la ressource si les conditions sont remplies.

L’objet est la cible à laquelle 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. Avec le champ S’applique, les utilisateurs disposent d’un contrôle granulaire sur les enregistrements spécifiques auxquels cette ACL s’appliquera.

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


Type	Nom	Objet sécurisé
enregistrement	[incident]. [--Aucun--]	La table Incident.
enregistrement	[incident]. [actif]	Champ Actif de la table Incident.
enregistrement	[incident] S’applique à : priorité = P1	Uniquement les incidents de priorité 1 dans la table des incidents.
REST_Endpoint	user_role_inheritance	Enregistrement de l’API REST scriptée user_role_inheritance.

Chaque opération décrit une action valide que le système peut entreprendre 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
enregistrement	[incident]. [-- Aucun --]	créer	Création d’enregistrements dans la table Incident.
enregistrement	[incident]. [actif]	écrire	Mise à jour du champ Actif dans la table Incident.
REST_Endpoint	user_role_inheritance	exécuter	Exécution de l’API REST user_role_inheritance scriptée.

Les conditions spécifient quand une personne peut accéder à l’objet nommé et à l’opération. Les administrateurs de sécurité peuvent spécifier les exigences de condition en ajoutant :

Un ou plusieurs rôles d’utilisateur à la liste des rôles requis .
Un ou plusieurs attributs de sécurité doivent être évalués pour être vrais.
Une ou plusieurs conditions de données.
Script qui évalue 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 remplir toutes les conditions répertoriées dans un contrôle d’accès. Par exemple, ce contrôle d’accès limite l’accès à la vue des opérations sur la table d’incidents.

ACL sur un enregistrement d’incident.

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


Type de condition	Besoin	Description
Demande un rôle	Nécessite un rôle : itil	Autoriser uniquement les utilisateurs ayant le rôle itil à mettre à jour les incidents.
Attributs de sécurité	UserIsAuthenticated	Utilisateurs authentifiés uniquement pour mettre à jour les incidents.
Condition de données	[État de l’incident] [n’est pas] [Fermé]	Autoriser uniquement les mises à jour des enregistrements d’incidents actifs.

S’applique au comportement

Le champ S’applique à détermine si une ACL s’applique aux enregistrements, tandis que la condition de données évalue une ACL déjà appliquée. S’applique à spécifie si l’ACL affecte un enregistrement spécifique ; si elle est vide, l’ACL s’applique à tous les enregistrements. S’applique à peut être utilisé pour l’application granulaire de l’ACL, tandis que « Condition de données » est un critère d’évaluation.

Remarque :

S’applique à est sensible à la casse.

Refuser par défaut le comportement

Par défaut, le moteur d’ACL refuse complètement l’accès si une ACL est vide ou non valide. Les ACL vides sont définies comme des ACL sans un ou plusieurs de ces composants :

Rôle défini
Attribut de sécurité
Condition de données
Script

Les ACL non valides sont définies comme suit :

ACL ayant des rôles qui n’existent pas (par exemple, n’avoir aucune ligne dans la base de données)
ACL avec des attributs de sécurité qui n’existent pas (par exemple, n’ont pas de ligne dans la base de données)
ACL avec un script qui contient « answer=true » ou « true »

Si le système détecte que l’utilisateur crée une ACL, il l’invite à sélectionner un rôle ou un attribut de sécurité existant.

Système invitant l’utilisateur à sélectionner.

Processus d’évaluation ACL

Une règle ACL n’accorde à un utilisateur l’accès à un objet que si l’utilisateur remplit toutes les conditions requises par la règle ACL correspondante.

La condition doit être évaluée comme vraie.
Le script doit avoir la valeur vrai ou renvoyer une variable de réponse avec la valeur vrai.
L’utilisateur doit disposer de l’un des rôles dans 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 correspondantes au niveau de la table et au niveau du champ doivent toutes deux être évaluées comme vraies.

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 conditions requises pour accéder à l’objet et à l’opération. Si une règle de contrôle d’accès spécifie plusieurs conditions, l’utilisateur doit remplir toutes les conditions pour accéder à l’objet et à l’opération. L’échec d’une vérification de condition empêche l’utilisateur d’accéder à l’objet et à l’opération correspondants.

Si un utilisateur ne répond pas aux conditions de la première règle de correspondance, le système évalue les conditions de la règle de contrôle d’accès suivante comme spécifié par l’ordre de traitement du contrôle d’accès. Si l’utilisateur ne remplit pas les conditions 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’existe aucune règle de contrôle d’accès correspondante pour l’objet et l’opération demandés, le système accorde à l’utilisateur l’accès à celui-ci. En pratique, il est rare que le système ne trouve aucune règle correspondante, 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 à laquelle l’utilisateur a échoué. Par exemple, en cas d’échec d’une opération de lecture, la règle ACL empêche l’utilisateur de voir l’objet. Selon l’objet sécurisé, la règle ACL masque un champ sur un formulaire, masque les 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 pré et post-requête

Votre instance vérifie les règles ACL avant et après qu’un utilisateur a 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 ACL pré-requête

Avant d’exécuter une requête de base de données, votre instance 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 examine uniquement 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 en compte ces données. 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 s’affiche pas pour l’utilisateur.

Vérification ACL post-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 y a 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 s’affiche pas pour l’utilisateur, mais l’utilisateur voit l’étiquette du champ si son rôle l’autorise.


Opération	Résultats de l’échec d’une règle ACL sur l’objet
exécuter	L’utilisateur ne peut pas exécuter de scripts sur un enregistrement ou une page d’interface utilisateur.
créer	L’utilisateur ne peut pas voir l’action Nouvelle interface utilisateur dans les 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 peut être évaluée comme fausse. Les champs des nouveaux enregistrements sont considérés comme vides jusqu’à ce que l’enregistrement soit enregistré.
Lire	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 des protocoles API tels que les services web.
écrire	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 des protocoles API tels que les services web.
supprimer	L’utilisateur ne peut pas voir l’action d’interface utilisateur Supprimer dans les formulaires. L’utilisateur ne peut pas non plus supprimer d’enregistrements d’une table à l’aide des 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 ou 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 à l’aide d’une règle ACL.
report_view	L’utilisateur ne peut pas afficher le contenu d’un rapport dans la table ACL ou dans 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.

Exigences 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 remplir les conditions de deux règles ACL : Toutes les règles ACL génériques pour l’objet (le cas échéant pour l’opération). Première règle ACL qui correspond au nom de l’objet (le cas échéant, règle ACL existe pour l’opération).	Par défaut, il n’existe aucune règle générique (*) 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 remplir les conditions 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érique () pour les opérations de création, de lecture, d’écriture et de suppression et des règles de champ générique (.*) 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é de comportement par défaut (glide.sm.default_mode) du gestionnaire de sécurité détermine si les utilisateurs peuvent accéder aux objets qui ne correspondent qu’aux règles ACL de la table à caractères génériques. 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 du champ à caractère générique (*.*) pour l’opération de création réutilise les mêmes conditions que l’opération d’écriture. Cela signifie que les conditions de création sont les mêmes que les conditions 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 moment dans l’ordre de traitement

Si deux règles ou plus correspondent en même temps dans l’ordre de traitement, l’utilisateur doit satisfaire à l’une des conditions des règles ACL pour accéder à l’objet. Par exemple, si vous créez deux règles ACL de champ pour incident.number, l’utilisateur qui transmet une règle a accès au champ numéro, qu’il ait échoué ou non à une autre règle ACL de champ au même moment 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 Accéder à un rôle privilégié pour obtenir des instructions.

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

Vous pouvez créer des règles ACL pour des 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 comportant au moins un champ qui est dans le même champ d’application que la règle ACL.

Pour les tables qui se trouvent 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 tout autre objet qui est dans le 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 est dans le même champ d’application, vous pouvez utiliser un script pour évaluer les conditions.
- Si la table se trouve dans un périmètre différent, vous ne pouvez pas utiliser de script pour évaluer les conditions.
Vous ne pouvez pas créer ou modifier des règles 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 à une ACL dans un périmètre différent.
Vous ne pouvez créer des règles de table générique (*) que dans le champ d’application global.
Vous pouvez créer des règles de champ générique (*) uniquement pour les tables du même champ d’application que la règle ACL.