Cette page explique comment les administrateurs et les utilisateurs du contrôle des accès basé sur les rôles pour les données (RBAC pour les données) peuvent attribuer des niveaux d'accès aux listes de référence.
Une liste de référence est une liste de valeurs (par exemple, des adresses IP) utilisées pour faire correspondre et filtrer les données dans la recherche UDM et les règles de détection. En attribuant des niveaux d'accès à une liste de référence, vous pouvez contrôler les utilisateurs et les ressources (par exemple, les règles et les instances de recherche UDM) qui peuvent y accéder et l'utiliser.
Pour ajouter des identifiants à une liste de référence, vous devez avoir accès à tous les identifiants que vous souhaitez ajouter. Vous ne pouvez pas ajouter de champs d'application auxquels vous n'avez pas accès.
Le RBAC des données a un impact sur les listes de référence de la manière suivante :
Si le RBAC des données est activé avant l'attribution de niveaux d'accès aux listes de référence, toutes les listes de référence existantes se voient automatiquement attribuer un niveau d'accès global. Attribuez des niveaux d'accès à chaque liste de référence en fonction de vos exigences de contrôle des accès aux données.
Le contrôle RBAC des données est activé après l'attribution de niveaux d'accès aux listes de référence : les listes de référence avec un niveau d'accès défini fonctionnent sur les données ingérées en fonction de leurs niveaux d'accès définis, même avant l'activation du contrôle RBAC des données.
Un utilisateur limité et un utilisateur global disposent de droits d'accès différents, avec les variations suivantes :
Un utilisateur soumis à des niveaux d'accès peut créer une liste de référence avec tout ou partie des niveaux d'accès qui lui sont attribués.
Un utilisateur global peut créer une liste de référence sans niveau d'accès (une liste de référence que tous les utilisateurs peuvent utiliser) ou une liste de référence avec niveau d'accès.
Pour ajouter des autorisations à une liste de référence :
Dans la fenêtre Gestionnaire de listes, sélectionnez la liste à laquelle vous souhaitez ajouter des niveaux d'accès.
Dans l'onglet Détails, dans le menu Attribution du champ d'application, sélectionnez tous les champs d'application auxquels la liste de référence doit avoir accès.
Cliquez sur Enregistrer les modifications.
Les autorisations sont ajoutées à la liste de référence.
Mettre à jour les champs d'application dans une liste de référence
Pour mettre à jour les niveaux d'accès dans une liste de référence, vous devez avoir accès à tous les niveaux d'accès aux données que vous souhaitez ajouter à la liste de référence. Vous ne pouvez pas ajouter des niveaux d'accès auxquels vous n'avez pas accès.
Les considérations suivantes s'appliquent lorsque vous mettez à jour une liste de références :
Vous ne pouvez supprimer des niveaux d'accès d'une liste de références que si toutes les règles existantes qui utilisent la liste de références restent fonctionnelles après la modification.
Par exemple, une mise à jour d'une liste de référence des portées A et B vers la portée A n'est pas autorisée si une règle avec la portée B utilise la liste de référence. De même, la mise à jour d'une liste de référence pour passer d'une portée non définie à la portée A n'est pas autorisée si une règle avec la portée B utilise la liste de référence.
Un utilisateur limité peut supprimer un champ d'une liste de références, ce qui peut entraîner la perte d'accès à cette liste pour un autre utilisateur limité.
Par exemple, un utilisateur disposant des niveaux d'accès A et B peut supprimer le niveau d'accès B d'une liste de référence avec les niveaux d'accès A et B. Après ce changement, l'utilisateur peut toujours utiliser la liste de références, mais un autre utilisateur disposant uniquement du champ d'application B ne peut plus afficher ni accéder à la liste de références.
Si vous mettez à jour les niveaux d'accès pour en ajouter d'autres, certains utilisateurs risquent de perdre leur accès en modification à la liste de référence.
Par exemple, un utilisateur disposant des niveaux d'accès A et B peut ajouter le niveau d'accès B à une liste de référence qui possède le niveau d'accès A. Après ce changement, l'utilisateur peut toujours modifier la liste de références, mais un autre utilisateur disposant uniquement du champ d'application A ne peut plus le faire.
Pour mettre à jour les niveaux d'accès dans une liste de référence, procédez comme suit :
Dans la fenêtre Gestionnaire de listes, sélectionnez la liste à laquelle vous souhaitez ajouter des niveaux d'accès.
Dans l'onglet Détails, dans le menu Attribution du champ d'application, sélectionnez tous les champs d'application auxquels la liste de référence doit avoir accès. Décochez les champs auxquels la liste de référence ne doit pas avoir accès.
Cliquez sur Enregistrer les modifications.
L'attribution du champ d'application de la liste de référence est mise à jour.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eData RBAC allows administrators to assign scopes to reference lists, controlling which users and resources can access and use them for matching and filtering data in UDM Search and detection rules.\u003c/p\u003e\n"],["\u003cp\u003eScoped users can create reference lists with their assigned scopes, while global users can create either unscoped or scoped lists.\u003c/p\u003e\n"],["\u003cp\u003eWhen adding or updating scopes to a reference list, users must have access to all scopes they intend to add, and removing scopes is restricted to ensure existing rules using the list remain functional.\u003c/p\u003e\n"],["\u003cp\u003eUpdating scopes can cause some users to lose edit or view access to the reference lists, depending on their scopes and the changes made to the reference list.\u003c/p\u003e\n"]]],[],null,["Configure data RBAC for reference lists \nSupported in: \nGoogle secops [SIEM](/chronicle/docs/secops/google-secops-siem-toc)\n\nThis page describes how *data role-based access control* (*data RBAC*)\nadministrators and users can assign scopes to reference lists.\nA reference list is a list of values (for example, IP addresses) that are used\nfor matching and filtering data in UDM Search and detection rules. By assigning\nscopes to a reference list, you can control which users and resources (for example,\nrules and UDM search instances) can access and utilize it.\n\nTo understand how data RBAC works, see [Overview of Data RBAC](/chronicle/docs/administration/datarbac-overview).\n\nAdd scopes to reference list\n\nTo add scopes to a reference list, you must have access to all the scopes that\nyou intend to add. You cannot add scopes that you don't have access to.\n\nData RBAC impacts reference lists in the following ways:\n\n- **Data RBAC is enabled *before* assigning scopes to reference lists:** all existing\n reference lists are automatically assigned global scope. Assign\n scopes to each reference list according to your data access control requirement.\n\n- **Data RBAC is enabled *after* assigning scopes to reference lists**: scoped\n reference lists operate on ingested data according to their defined scopes, even\n before data RBAC is enabled.\n\nA scoped user and a global user have different access permissions, with the\nfollowing variation:\n\n- A scoped user can create a scoped reference list with all or a subset of\n scopes that are assigned to them.\n\n- A global user can create either an unscoped reference list (a reference list\n that all the users can use) or a scoped reference list.\n\nTo add scopes to a reference list, do the following:\n\n1. [Log in to Google Security Operations](/chronicle/docs/log-in-to-ui).\n\n2. Click **Detection** \\\u003e **Lists**.\n\n3. In the **List manager** window, select the list that you want to add scopes\n to.\n\n4. In the **Details** tab, in the **Scope assignment** menu, select all the\n scopes that the reference list must have access to.\n\n5. Click **Save edits**.\n\nThe scopes are added to the reference list.\n\nUpdate scopes in a reference list\n\nTo update the scopes in a reference list, you must have access to all the data\nscopes that you intend to add to the reference list. You cannot add scopes that\nyou don't have access to.\n\nThe following considerations apply when updating a reference list:\n\n- Removing scopes from a reference list is allowed only if all the existing\n rules that use the reference list stay functional with the change.\n\n For example, an update for a reference list from scopes A and B to scope A\n is not allowed if a rule with scope B uses the reference list. Similarly,\n an update for a reference list from being unscoped to scope A is not allowed\n if a rule with scope B uses the reference list.\n- A scoped user can remove a scope from a reference list which can cause\n another scoped user to lose access to the reference list.\n\n For example, a user with scopes A and B can remove scope B from a reference\n list with scopes A and B. After this change, the user can still use the\n reference list, but another user with only scope B can no longer view or\n access the reference list.\n- Updating scopes to add more scopes can cause some users to lose their edit\n access to the reference list.\n\n For example, a user with scopes A and B can add scope B to a reference list\n that has scope A. After this change, the user can still edit the reference\n list, but another user with only scope A is no longer able to edit the\n reference list.\n\nTo update the scopes in a reference list, do the following:\n\n1. [Log in to Google Security Operations](/chronicle/docs/log-in-to-ui).\n\n2. Click **Detection** \\\u003e **Lists**.\n\n3. In the **List manager** window, select the list that you want to add scopes to.\n\n4. In the **Details** tab, in the **Scope assignment** menu, select all the\n scopes that the reference list should have access to. Deselect the scopes that\n the reference list shouldn't have access to.\n\n5. Click **Save edits**.\n\nThe scope assignment of the reference list is updated.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]
