Gérer l’accès

Une politique d’accès contrôle qui peut voir quoi dans les données d’un espace de travail. Une même politique peut faire l’une ou l’autre de trois choses :

• Restreindre des colonnes (sécurité au niveau des membres) — cacher certaines dimensions ou mesures à certaines personnes. Les analystes voient salary; les autres non.
• Restreindre des lignes (sécurité au niveau des lignes) — filtrer les données pour ne garder que les lignes qu’une personne est autorisée à voir. Chaque vendeur ne voit que ses propres comptes.
• Masquer des valeurs (masquage de données) — garder une colonne visible mais en remplacer les valeurs, de sorte qu’une personne sache que le champ existe sans voir les données réelles.

Les politiques sont définies dans le modèle sémantique, sur les cubes et les vues qu’elles protègent. Cette page explique leur comportement; pour le YAML exact, consultez la référence des politiques d’accès.

Comment les politiques déterminent l’accès

Les politiques s’appuient sur les groupes et les attributs d’utilisateur que vous assignez aux membres (voir la gestion des utilisateurs) :

• Une politique cible un ou plusieurs groupes — elle s’applique aux personnes de ces groupes.
• À l’intérieur d’une politique, les attributs d’utilisateur permettent de personnaliser la règle. Un filtre du type « salesperson_id égale l’attribut salesperson_id de l’utilisateur » donne à chaque vendeur une tranche différente du même ensemble de données, à partir d’une seule politique.

Refus par défaut

La règle la plus importante : dès qu’une politique est définie sur un cube ou une vue, l’accès est refusé à toute personne qui ne correspond à aucune politique. Avant qu’une politique existe, les données sont ouvertes à l’espace de travail; dès que vous en ajoutez une, vous faites passer cet ensemble de données en mode liste d’autorisation. Quand vous protégez un ensemble de données, assurez-vous donc que chaque groupe qui devrait conserver l’accès dispose d’une politique — y compris, souvent, un groupe d’administrateurs ou d’analystes avec un accès complet.

Correspondre à plusieurs politiques

Une personne peut appartenir à plusieurs groupes et donc correspondre à plusieurs politiques à la fois. Dans ce cas, les politiques se combinent :

• Les colonnes s’additionnent — la personne voit l’union de toutes les colonnes permises par ses politiques correspondantes.
• Les filtres de lignes se cumulent — la personne ne voit que les lignes qui satisfont les filtres de toutes ses politiques correspondantes (l’intersection).

En bref : correspondre à plus de politiques ne peut qu’élargir les colonnes visibles, et ne peut que réduire les lignes.

Groupes par défaut : l’agent et l’interface

Chaque requête porte l’un de deux groupes intégrés, selon qui interroge les données :

Groupe	Ajouté automatiquement quand…
streya-llm	L’agent interroge les données pour répondre à une question.
streya-ui	Les données sont interrogées directement depuis l’interface par une personne.

Cela vous permet de traiter différemment l’agent et l’humain pour les mêmes données. L’usage canonique concerne les renseignements personnels (PII) : masquez les colonnes sensibles pour streya-llm, afin que l’agent puisse raisonner sur la forme des données sans jamais lire les détails personnels bruts, tout en permettant à streya-ui d’afficher les vraies valeurs à la personne autorisée à les voir.

# Masquer le courriel pour l’agent, l’afficher dans l’interface
access_policy:
  - group: streya-ui
    member_level:
      includes: "*"

  - group: streya-llm
    member_level:
      includes: "*"
    member_masking:
      includes:
        - email
        - phone

Rédiger des politiques d’accès

Les politiques vivent aux côtés du reste de votre modèle et sont définies avec l’équipe Streya pendant la modélisation. La référence des politiques d’accès documente le schéma complet — ciblage des groupes, conditions, règles de colonnes, masquage et filtres de lignes — avec des exemples.