Explorer les 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 en cours de sécurisation
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’ils refusent l’accès à l’objet si les conditions ne sont pas remplies.


Type de décision	Description
Refuser sauf	Restreignez l’accès à la ressource en refusant explicitement l’accès, sauf si certaines conditions sont respectées. 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 vérifiées.

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é
record	[incident]. [--Aucun--]	La table Incident.
record	[incident]. [actif]	Le champ Actif de la table Incident.
record	[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 user_role_inheritance scriptée.

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
record	[incident]. [-- Aucun --]	créer	Création d’enregistrements dans la table Incident.
record	[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 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 dans la liste Exige 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 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 aux opérations d’affichage 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	Uniquement les utilisateurs authentifiés pour mettre à jour les incidents.
Condition de données	[État de l’incident] [n’est pas] [Fermé]	Autorisez 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 des ACL, tandis que « Condition de données » est un critère d’évaluation.

Remarque :

S’applique à est sensible à la casse.

Refuser le comportement par défaut

Par défaut, le moteur ACL refuse complètement l’accès si une ACL est vide ou invalide. 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 ayant des rôles qui n’existent pas (par exemple, qui n’ont pas de ligne dans la base de données)
ACL avec des attributs de sécurité qui n’existent pas (par exemple, qui 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 être évalué comme vrai ou renvoyer une variable de réponse avec la valeur vrai.
L’utilisateur doit disposer de 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 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 possède les conditions requises pour accéder à l’objet et à l’opération. Si une règle de contrôle d’accès spécifie plus d’une condition, 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 spécifiée 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 effets du refus d’accès à un objet dépendent de la règle ACL à 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 dans un formulaire, masque des lignes dans 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 a effectué 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 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 ne porte que sur les rôles de l’utilisateur et vérifie si ces rôles autorisent l’accès à des 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 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 s’affiche pas pour l’utilisateur. Toutefois, 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 de 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 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ée pour contrôler les champs qui doivent être enregistrés lorsqu’un modèle est créé.
add_to_list	L’utilisateur ne peut pas afficher ou personnaliser des colonnes spécifiques dans les réglages 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.

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 répondre aux 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). 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 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 répondre aux conditions de deux règles ACL : Première règle ACL qui correspond au champ de l’enregistrement (le cas échéant, une règle ACL existe pour l’opération). Première règle ACL correspondant à la table de l’enregistrement (le cas échéant, une règle ACL existe 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é 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 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 de 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 de 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 les Accéder à 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 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 se trouve dans le même champ d’application que la règle ACL.

Pour les tables dont le champ d’application est différent de celui 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 du même champ d’application que la règle ACL.
Vous pouvez créer une ACL pour un champ qui se trouve dans le même champ d’application que la règle ACL.
- Si la table se trouve 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 ou modifier de 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 champs génériques (*) uniquement pour les tables du même champ d’application que la règle ACL.