Politiques d’accès

access_policy est un tableau défini sur un cube ou une vue qui contrôle l’accès au niveau des colonnes et des lignes pour les personnes qui les interrogent. Pour les concepts et le comportement, voir gérer l’accès.

access_policy:
  - group: sales
    conditions:
      - if: "{ attributes.is_active }"
    member_level:
      excludes:
        - cost
    member_masking:
      includes:
        - customer_email
    row_level:
      filters:
        - member: salesperson_id
          operator: equals
          values: ["{ attributes.salesperson_id }"]

Chaque entrée constitue une politique. Une politique s’applique à une personne lorsque son groupe cible correspond et que toutes ses conditions sont vraies. Dès qu’une politique existe sur un cube ou une vue, les personnes qui ne correspondent à aucune politique se voient refuser l’accès entièrement.

Propriétés d’une politique

Propriété	Type	Description
group	chaîne	Le groupe auquel la politique s’applique. Utilisez "*" pour viser tout le monde.
groups	tableau	Plusieurs groupes dans une même politique — un raccourci pour éviter de la répéter par groupe.
conditions	tableau	Conditions supplémentaires; la politique s’applique seulement si toutes sont vraies. Voir conditions.
member_level	objet	Quelles colonnes sont visibles. Voir member_level.
member_masking	objet	Quelles colonnes visibles ont leurs valeurs masquées. Voir member_masking.
row_level	objet	Quelles lignes sont visibles. Voir row_level.

Fournissez exactement l’une des propriétés group ou groups. Les trois blocs de règles (member_level, member_masking, row_level) sont chacun facultatifs; une politique qui n’en contient aucun accorde simplement l’accès complet aux personnes qui y correspondent.

conditions

Une liste de conditions qui doivent toutes être vraies pour que la politique prenne effet. Chacune est une expression if, qui référence habituellement les attributs d’utilisateur de la personne qui interroge, via attributes.

conditions:
  - if: "{ attributes.region }"               # l'attribut est présent / vrai
  - if: "{ attributes.clearance_level } >= 3" # comparaison

Utilisez les conditions pour activer une politique personne par personne — par exemple, appliquer une règle seulement au personnel à temps plein ou à une région donnée — sans créer un groupe distinct.

member_level

Contrôle quelles dimensions et mesures la politique expose. Fournissez soit includes, soit excludes, pas les deux.

member_level:
  includes: "*"          # toutes les colonnes…
  excludes:              # …invalide en présence de includes — choisissez-en un
    - cost
    - margin

Clé	Signification
includes	Liste d’autorisation : seules ces colonnes sont visibles. "*" signifie toutes.
excludes	Liste de blocage : toutes les colonnes sont visibles, sauf celles-ci.

member_masking

Garde les colonnes visibles, mais remplace leurs valeurs. Utilisez-le quand une personne doit savoir qu’un champ existe — et pouvoir l’utiliser dans ses requêtes — sans lire les données brutes. Se définit aux côtés de member_level dans la même politique. Fournissez soit includes, soit excludes, pas les deux.

member_masking:
  includes:              # masquer ces colonnes
    - customer_email
    - phone

Clé	Signification
includes	Masque ces colonnes. "*" masque toutes les colonnes visibles.
excludes	Masque tout, sauf celles-ci.

Le masquage diffère de l’exclusion par member_level : les colonnes exclues disparaissent; les colonnes masquées restent interrogeables, mais retournent des valeurs obscurcies.

La propriété mask

Une colonne listée dans member_masking doit définir une propriété mask sur sa dimension ou sa mesure, qui détermine la valeur de remplacement lors du masquage. Le masque est soit une valeur statique, soit une expression SQL :

dimensions:
  - name: customer_email
    sql: customer_email
    type: string
    mask:
      sql: "CONCAT(LEFT({CUBE}.customer_email, 2), '***')"

  - name: customer_zip
    sql: customer_zip
    type: string
    mask: "REDACTED"        # remplacement statique

measures:
  - name: total_salary
    sql: salary
    type: sum
    mask: -1                # remplacement statique

Sans mask, member_masking n’a rien à substituer — définissez-en un sur chaque colonne que vous comptez masquer.

row_level

Filtre les lignes que la politique expose. Contient un tableau filters; chaque filtre compare une colonne à une ou plusieurs valeurs.

row_level:
  filters:
    - member: region
      operator: equals
      values: ["{ attributes.region }"]
    - or:
        - member: status
          operator: equals
          values: ["active"]
        - member: status
          operator: equals
          values: ["trial"]

Clé de filtre	Signification
member	La dimension sur laquelle filtrer.
operator	Opérateur de comparaison — equals, notEquals, contains, startsWith, endsWith, gt, gte, lt, lte, set, notSet, inDateRange.
values	Tableau de valeurs de comparaison. Les entrées peuvent être des littéraux ou des références attributes comme "{ attributes.salesperson_id }".

Combiner les filtres

Les filtres de premier niveau du tableau sont combinés par AND — chacun doit passer. Utilisez des blocs explicites and / or pour imbriquer une autre logique :

filters:
  - and:
      - member: region
        operator: equals
        values: ["{ attributes.region }"]
      - or:
          - member: tier
            operator: equals
            values: ["gold"]
          - member: tier
            operator: equals
            values: ["platinum"]

Plusieurs politiques correspondantes

Une personne peut correspondre à plusieurs politiques (par l’entremise de plusieurs groupes). Les résultats se combinent :

• Colonnes — l’union de ce que chaque politique correspondante autorise. Correspondre à plus de politiques ne peut que révéler plus de colonnes.
• Filtres de lignes — l’intersection : la personne ne voit que les lignes qui satisfont chaque politique correspondante. Correspondre à plus de politiques ne peut que restreindre davantage les lignes.

Attributs d’utilisateur et groupes intégrés

• attributes expose les attributs d’utilisateur de la personne qui interroge — les paires clé-valeur (salesperson_id, region, …) définies sur son adhésion. Référencez-les sous la forme { attributes.<key> } dans conditions et dans les valeurs de row_level.
• Deux groupes intégrés s’ajoutent automatiquement à chaque requête : streya-llm quand l’agent interroge, et streya-ui quand une personne interroge depuis l’interface. Ciblez-les comme n’importe quel autre groupe — voir le guide pour le patron de masquage des renseignements personnels.