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

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

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

Composants de l’ACL

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


Type de décision	Description
Refuser à moins que	Restreignez l’accès aux ressources 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	Autoriser l’accès à la ressource si les conditions sont réussies.

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. 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 d’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 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
enregistrement	[incident]. [-- Aucun --]	créer	Création d’enregistrements dans la table Incident.
enregistrement	[incident]. [actif]	write	Mise à jour du champ Actif dans la table Incident.
REST_Endpoint	user_role_inheritance	execute	Exécution de l’API REST basée sur un script user_role_inheritance.

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

Un ou plusieurs rôles d’utilisateur à la liste Requiert un rôle .
Un ou plusieurs attributs de sécurité doivent être évalués pour être vrais.
Une ou plusieurs conditions de données.
Script qui évalue sur vrai ou faux ou qui définit la variable de réponse sur vrai ou faux.

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

ACL sur un enregistrement d’incident.

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


Type de condition	Besoin	Description
Demande un rôle	Exige role :itil	Autorisez uniquement les utilisateurs disposant du rôle itil à mettre à jour les incidents.
Attributs de sécurité	UserIsAuthenticated	Seuls les utilisateurs authentifiés peuvent 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.

Comportement de refus par défaut

Par défaut, le moteur 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 :

ACL avec des rôles qui n’existent pas (par exemple, n’ont pas de 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 avoir l’un des rôles de la liste des rôles requis. Si la liste est vide, cette condition est évaluée comme vrai.
[Règles ACL d’enregistrement uniquement] Les règles ACL correspondantes au niveau de la table et au niveau du champ doivent toutes les deux être évaluées sur vrai.

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 remplit les 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 correspondante suivante, telles que spécifiées 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’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 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 du refus d’accès à un objet dépendent de la règle ACL que l’utilisateur a défaillante. 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 dans 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 de l’é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 effectue une requête. Étant donné que différentes informations 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 d’exécuter une requête de base de données, l’instance vérifie les règles ACL de 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 lui est pas présentée.

Vérification de l’ACL après 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 d’interface utilisateur.
créer	L’utilisateur ne peut pas voir la nouvelle action d’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 est toujours évaluée comme faux. 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 d’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 il ne peut pas mettre à jour des 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 les 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 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 avec 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.

ACL correspondant aux exigences pour les objets


Type d'objet	Règles ACL de correspondance 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, une règle ACL existe pour l’opération). La première règle ACL qui correspond au nom de l’objet (si une règle ACL existe pour l’opération).	Par défaut, il n’existe pas de 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 : La première règle ACL qui correspond au champ de l’enregistrement (si une règle ACL existe pour l’opération). La première règle ACL qui correspond à la table de l’enregistrement (si une règle ACL existe 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 champ génériques (.*) pour les opérations personalize_choices, create et save_as_template. Lorsque vous créez une table, créez des règles ACL pour la table, à moins que vous ne souhaitiez 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 ne correspondent qu’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 du champ 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 point dans l’ordre de traitement

Si deux règles ou plus correspondent au même point de l’ordre de traitement, l’utilisateur doit passer l’une des conditions 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 Numéro, qu’il ait ou non échoué à 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 comportant 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 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 périmètre que la règle ACL.
- Si la table est dans le même périmètre, 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 ni modifier les règles ACL pour les 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 d’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ériques (*) uniquement pour les tables dans le même champ d’application que la règle ACL.