Ces bonnes pratiques reflètent les recommandations partagées par une équipe pluridisciplinaire de spécialistes Looker expérimentés. Ces insights sont le fruit d'années d'expérience avec les clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour être adaptées à la plupart des utilisateurs et des situations, mais faites toujours preuve de discernement lors de leur mise en œuvre.
Cette page fournit aux administrateurs d'instances Looker un exemple guidé pour configurer le contrôle des accès au contenu. Nous évoquerons le processus d'implémentation, en commençant par un nouveau projet, puis en examinant les modèles, les ensembles de modèles, les ensembles d'autorisations, les groupes, les rôles et les attributs utilisateur.
Commençons par une analogie pour comprendre les principales fonctionnalités de Looker dans ce contexte:
Un projet est comme une maison.Un model est une pièce de la maison remplie d'éléments spécifiques.
Un ensemble de modèles est un groupe de pièces ou une pièce unique (chambres, cuisine).
Un ensemble d'autorisations est une checklist d'activité spécifiant les actions que les utilisateurs peuvent effectuer dans une pièce (manger, jouer, dormir).
Un groupe permet d'associer des personnes ayant des caractéristiques communes (adultes, enfants, invités).
Un rôle permet d'attribuer à des groupes de personnes des checklists d'activité dans différents ensembles de pièces.
Un attribut utilisateur est une clé qui permet d'accéder à des objets spéciaux dans la maison (théière, outils électriques).
Scénario
Voici un exemple de start-up avec des équipes dédiées aux finances, aux ventes et aux produits. La PDG est notre seule administratrice. Elle souhaite que chaque équipe ne puisse voir que le contenu qui la concerne, à l'exception que le vice-président de chaque équipe doit avoir accès au contenu de toutes les équipes. Elle souhaite disposer d'un accès différent aux fonctionnalités pour les employés standards, les responsables et les vice-présidents.
- Les employés standards doivent pouvoir consulter et explorer les données dans leurs propres modèles.
- Les administrateurs doivent disposer d'un accès standard, et pouvoir télécharger et planifier des contenus.
- Les vice-présidents doivent avoir presque tous les droits, à l'exception de quelques-uns réservés au PDG.
Le PDG souhaite que les commerciaux puissent afficher les données de leurs propres activités, mais pas les chiffres des ventes d'un autre vendeur. Cependant, les responsables des ventes doivent être en mesure de voir les chiffres de chaque vendeur. Enfin, elle souhaite masquer des champs financiers contenant des informations sensibles pour les employés standards qui utilisent ce modèle.
L’organigramme se trouve ci-dessous:
Le graphique ci-dessus révèle la structure organisationnelle suivante pour notre exemple de start-up:
- PDG
- Vice-président des finances
- Responsable financier
- Comptable
- Vice-président des ventes
- Responsable commercial Ouest
- Commercial West
- Responsable commercial Est
- Commercial Est
- VP du département Produit
- Responsable produit
- Engineer
La mise en œuvre des contrôles d'accès souhaités nécessitera les étapes suivantes:
- Créer un projet:un projet est le lien structurel entre une connexion à une base de données et des modèles de données.
- Ajouter des modèles:décidez quelles données seront présentées aux utilisateurs.
- Créer des ensembles de modèles:regroupez les modèles pertinents.
- Créer des ensembles d'autorisations:définissez explicitement les actions que les utilisateurs peuvent effectuer dans un ensemble de modèles.
- Créer des groupes:regroupez des utilisateurs similaires.
- Créer des rôles:créez des connexions entre des ensembles de modèles, des ensembles d'autorisations et des groupes.
- Accès en modification au contenu:gérez les tableaux de bord et les Looks que les utilisateurs peuvent consulter à l'aide de dossiers.
- Ajouter des filtres de données:filtrez davantage les données auxquelles des utilisateurs spécifiques peuvent accéder dans un modèle.
1. Créer un projet
Tout d'abord, nous avons besoin d'un projet, c'est-à-dire d'un conteneur pour un ou plusieurs modèles. Si vous avez déjà configuré un projet, vous pouvez ignorer cette étape. Sinon, vous pouvez accéder à la page Projets LookML en sélectionnant Projects (Projets) dans la section Develop (Développer) de Looker, puis en sélectionnant New LookML Project (Nouveau projet LookML) pour créer un projet. Pour des instructions plus détaillées sur la création d'un projet, consultez la page de documentation Créer un projet LookML.
Sur la page Nouveau projet, nous allons créer un projet avec les paramètres suivants:
- Dans la section Name (Nom), nous attribuons un nom au projet.
- Dans la section Starting Point (Point de départ), nous sélectionnons Generate Model from Database Schema (Générer un modèle à partir du schéma de base de données).
- Dans le menu déroulant Connexion, sélectionnez le nom de la connexion à votre base de données.
- Dans la section Build Views from (Créer des vues à partir de), pour cet exemple, nous sélectionnons l'option All Tables (Toutes les tables) afin que le générateur LookML crée un fichier de vue pour chaque table de votre base de données.
Une fois que vous avez configuré les paramètres souhaités pour le nouveau projet, sélectionnez Créer un projet.
Lorsque vous créez un projet, vous êtes redirigé vers le modèle LookML généré automatiquement. À ce stade, vous devez utiliser le bouton Configurer Git pour configurer le contrôle des versions pour le projet. Pour obtenir des instructions détaillées sur la configuration du contrôle des versions, consultez la page de documentation Configurer et tester une connexion Git.
2. Ajouter des modèles
Un model de données est comme un portail personnalisable dans la base de données. Chaque modèle peut présenter des données différentes aux utilisateurs. Dans notre exemple, nos commerciaux ont besoin de données différentes de celles de nos ingénieurs. Nous allons donc ajouter des modèles distincts afin de présenter les informations appropriées de la base de données à chaque type d'utilisateur.
Dans notre projet LookML, nous ajouterons de nouveaux fichiers de modèle LookML avec les noms de chacun des modèles souhaités (finance, sales et product). Veillez à définir au moins une exploration dans chaque fichier de modèle. Cela nous permettra de sélectionner le modèle lors de la création des ensembles de modèles (sinon, ils n'apparaîtront pas dans la sélection). Pour en savoir plus sur l'utilisation du paramètre explore dans votre fichier de modèle, consultez la page Comprendre les fichiers de modèle et de vue.
Une fois les modèles ajoutés, nous devons encore les configurer. Pour configurer les modèles, revenons à la page Projects (Projets) de la section Develop (Développer), qui devrait maintenant afficher le texte en rouge "Configuration requise pour l'utilisation" à côté de chaque nom de modèle.
À côté de chaque modèle, sélectionnez Configurer. Nous allons vérifier que le nom de notre projet est correct, ainsi que les connexions que ce modèle pourra utiliser, puis que nous enregistrerons.
Une fois tous les modèles configurés correctement, les messages rouges sur le problème de configuration rencontrés précédemment n'apparaîtront plus.
N'oubliez pas que, dans Looker, l'autorisation see_lookml ou develop sur un modèle lui est accordée pour tous les modèles de ce projet. Par conséquent, vous devez créer des projets distincts si vous souhaitez partitionner les autorisations d'affichage ou de développement LookML. Sinon, créez simplement un nouveau modèle. Les autorisations du modèle sont suffisantes pour garantir que seules certaines personnes peuvent interroger certaines données.
Pour en savoir plus sur les autorisations, consultez notre documentation sur les rôles.
3. Créer des ensembles de modèles
Maintenant que les modèles de données de chaque service ont été configurés, nous allons ajouter le modèle correspondant à chaque service dans les ensembles de modèles que nous créons. Pour créer des ensembles de modèles, accédez à la page Rôles du panneau Administration, puis sélectionnez Nouvel ensemble de modèles. Pour en savoir plus sur la création d'ensembles de modèles, consultez la page de documentation Rôles.
Une fois les ensembles de modèles créés, ils s'affichent dans la section Ensembles de modèles de la page Rôles, comme illustré dans la capture d'écran suivante:
4. Créer des ensembles d'autorisations
Nous allons maintenant créer des ensembles d'autorisations à l'aide des ensembles de modèles que nous venons de créer. Comme indiqué lors de la configuration du scénario, nous souhaitons disposer de quatre niveaux d'autorisation correspondant aux quatre niveaux hiérarchiques de l'organigramme. Les niveaux supérieurs doivent inclure les autorisations des niveaux suivants. Dans notre scénario, nous allons identifier les ensembles d'autorisations comme suit:
- Le PDG dispose de l'autorisation Administrateur.
- Les vice-présidents disposent de l'autorisation Administrateur limité.
- L'autorisation Télécharger et partager des administrateurs est définie.
- L'autorisation Afficher et explorer est définie pour les employés standards.
Pour créer des ensembles d'autorisations, accédez à la page Rôles dans le panneau Administration et sélectionnez Nouvel ensemble d'autorisations. Pour chaque niveau d'autorisation, nous sélectionnerons les autorisations appropriées. En règle générale, les ensembles d'autorisations doivent se chevaucher le moins possible, chaque ensemble n'ajoutant que les autorisations spécifiques que nous souhaitons accorder aux utilisateurs disposant de cet ensemble d'autorisations. En effet, nous allons accorder à certains utilisateurs plusieurs ensembles d'autorisations et nous voulons savoir exactement ce que chacun d'eux permet. Cependant, en raison de l'arborescence, un certain chevauchement est souvent nécessaire.
Dans notre exemple, nous voulons que l'autorisation Afficher et explorer permette aux utilisateurs d'afficher le contenu, de poser des questions et d'enregistrer des cartes utiles. Nous allons donc leur accorder les autorisations associées à l'affichage du contenu (comme see_looks et see_user_dashboards), l'autorisation explore et l'autorisation save_content. Les exceptions notables sont see_lookml, que nous ne souhaitons peut-être que pour les développeurs, et see_sql, que nous réservons aux utilisateurs qui comprennent SQL et peuvent consulter la structure de la base de données. Toutes ces autorisations relèvent strictement de la branche access_data. Nous n'accordons aucune des autorisations see au bas de l'arborescence, car il s'agit d'autorisations d'administration.
Pour l'ensemble d'autorisations Télécharger et partager, nous ajouterons les autorisations associées au téléchargement, à la planification, au partage, à la création de Looks publics (qui permet le partage de Looks avec des utilisateurs qui n'utilisent pas Looker) et à see_schedules (car ils peuvent créer des planifications, il est logique qu'ils puissent également les consulter dans le panneau d'administration).
Les seuls champs qui ont été sélectionnés lors de la configuration des ensembles d'autorisations Vue et exploration et Télécharger et partager sont les autorisations parentes requises pour sélectionner les autorisations enfants ajoutées dans la branche access_data. Par conséquent, étant donné que les utilisateurs disposant des autorisations Télécharger et partager disposent également de l'autorisation Afficher et explorer, il n'est pas nécessaire d'inclure des autorisations telles que see_lookml_dashboards, see_user_dashboards et explore dans l'ensemble d'autorisations Télécharger et partager. En effet, ces autorisations ne contiennent aucune autorisation enfant nécessaire à l'ensemble d'autorisations Télécharger et partager.
Enfin, pour notre ensemble d'autorisations Administrateur limité, nous allons ajouter la plupart des autorisations d'administration au bas de l'arborescence, à l'exception des droits manage_models et sudo que le PDG souhaite uniquement pour son usage personnel. Cela se présente comme suit:
Une fois l'opération terminée, les ensembles d'autorisations incluront les autorisations suivantes:
- Administrateur: l'ensemble d'autorisations Administrateur, réservé au PDG de notre exemple d'entreprise, inclut toutes les autorisations.
- Administrateur limité: l'ensemble d'autorisations Administrateur limité inclut les autorisations
create_prefetches,login_special_email,manage_homepage,manage_spaces,see_alerts,see_datagroups,see_logs,see_pdts,see_queries,see_usersetupdate_datagroups. - Télécharger et partager: l'ensemble d'autorisations Télécharger et partager inclut les autorisations
access_data,create_public_looks,download_with_limit,download_without_limit,save_content,schedule_external_look_emails,schedule_look_emails,see_looks,see_schedules,send_outgoing_webhook,send_to_s3etsend_to_sftp. - Afficher et explorer: l'ensemble d'autorisations Afficher et explorer comprend les autorisations
access_data,create_table_calculations,explore,save_content,see_drill_overlay,see_lookml_dashboards,see_looksetsee_user_dashboards.
Vous pouvez afficher les autorisations appartenant à un ensemble d'autorisations existant en accédant à la section Ensembles d'autorisations de la page d'administration Rôles.
5. Créer des groupes
L'étape suivante consiste à créer les groupes et les utilisateurs dans un bucket. Nous allons créer des groupes pour les employés standards et les responsables de chaque service, car ils correspondront à terme aux différents rôles que nous créerons par la suite. Les vice-présidents seront dans leur propre groupe et le PDG n'a pas besoin d'un groupe. Une fois l'opération terminée, la page Groupes affiche les groupes suivants et leurs ID de groupe correspondants, qui sont générés automatiquement par Looker. Exemple :
| ID | Nom |
|---|---|
| 1 | Tous les utilisateurs |
| 3 | Finance |
| 4 | Ventes |
| 5 | Product |
| 7 | Responsable des ventes |
| 8 | Responsable produit |
| 9 | Responsable financier |
| 10 | Vice-présidents |
Une fois les groupes créés, nous devrons y ajouter des utilisateurs. Pour savoir comment ajouter des utilisateurs à des groupes, consultez la page de documentation Groupes.
Lorsque vous ajoutez des utilisateurs aux groupes que nous avons créés, rappelez-vous qu'en raison de la structure des autorisations, les groupes de niveau supérieur peuvent être inclus dans les groupes de niveau inférieur. Par exemple, nous voulons inclure les vice-présidents du groupe Finance et non ceux du groupe Produit. Une méthode efficace consiste à ajouter des utilisateurs aux groupes de niveau supérieur (comme les vice-présidents), afin de pouvoir les ajouter en tant que groupe aux niveaux inférieurs.
6. Créer des rôles
Maintenant que nos ensembles de modèles, d'autorisations et de groupes sont en place, nous pouvons les assembler à l'aide de rôles. Chaque rôle possède un seul ensemble d'autorisations et un seul ensemble de modèles, et peut inclure un ou plusieurs groupes. Étant donné que les rôles doivent inclure un ensemble de modèles, nous allons à nouveau créer des rôles pour les employés standards et pour les responsables de chaque service.
- Rôles standards: ces rôles incluent l'ensemble d'autorisations Afficher et explorer, ainsi que l'ensemble de modèles correspondant. Attribuez des rôles standards aux groupes standards et responsables de ce service, ainsi qu'au vice-président. Par exemple, attribuez le rôle Finances standard aux groupes Finance et Responsable financier, ainsi qu'au vice-président des finances.
- Rôles de gestionnaire:l'autorisation Télécharger et partager est définie pour les rôles de gestionnaire, ainsi que l'ensemble de modèles correspondant. Ces rôles doivent être attribués au groupe de responsables du service correspondant et au vice-président du service.
- Rôles de gestionnaire:l'autorisation Télécharger et partager est définie pour les rôles de gestionnaire, ainsi que l'ensemble de modèles correspondant. Ces rôles doivent être attribués au groupe de responsables du service correspondant et au vice-président du service.
- Rôle vice-président: le rôle de vice-président dispose de l'autorisation Administrateur limité et du modèle Tous. Ce rôle sera attribué au groupe VPs (VPs).
7. Modifier l'accès au contenu
L'étape suivante consiste à organiser nos autorisations d'accès aux dossiers de sorte que chaque groupe ait accès à son propre contenu (et uniquement à son propre contenu). Voici la disposition des dossiers dans notre exemple, qui peut être consultée en accédant à la page Accès au contenu du panneau d'administration:
L'accès aux dossiers suit les règles d'héritage hiérarchique. Pour en savoir plus, consultez notre documentation sur les niveaux d'accès et sur le contrôle des accès et la gestion des autorisations.
Conformément aux règles d'accès aux dossiers, nous souhaitons accorder un accès en lecture à tous les utilisateurs du dossier partagé. Nous allons accorder à chaque groupe un accès en lecture aux dossiers parents de l'arborescence située au-dessus de ceux auxquels le groupe aura accès. Ainsi, lorsque nous suivons l'arborescence, si nous ne voulons pas qu'un groupe puisse voir un dossier, nous n'incluons pas ce groupe pour accorder l'accès.
Nous pouvons accorder le niveau d'accès Gérer l'accès, modifier aux groupes d'un dossier pour lequel nous voulons contrôler qui peut voir ce dossier. Dans notre exemple, nous voulons uniquement que le PDG et les vice-présidents disposent de ces autorisations. Les autres utilisateurs disposeront uniquement d'un accès en lecture aux dossiers dont ils ont besoin.
8. Ajouter des restrictions d'accès aux données à l'aide d'attributs utilisateur
Cette section décrit les méthodes permettant d'empêcher des utilisateurs spécifiques d'accéder à des lignes ou des colonnes de données spécifiques d'un modèle auquel ils ont accès. N'oubliez pas que notre PDG souhaite que les commerciaux puissent consulter les données de leurs propres activités, mais pas celles des autres. En revanche, les responsables commerciaux doivent pouvoir consulter les chiffres de chaque vendeur. Pour ce faire, nous allons exploiter les attributs utilisateur et le paramètre sql_always_where.
Créer des attributs utilisateur
Nous allons d'abord créer un attribut utilisateur nommé access_level, qui n'est pas visible par les utilisateurs. Cela nous permettra de définir des niveaux d'accès pour les différents groupes dont nous disposons. Nous allons définir les valeurs suivantes lors de la création de l'attribut utilisateur:
- Nom :
access_level - Libellé: niveau d'accès
- Type de données: chaîne
- Accès utilisateur: modifier
- Masquer les valeurs: Non
Dans notre exemple, nous allons laisser l'option Définir une valeur par défaut non cochée.
Lors de la création du champ, nous allons configurer trois niveaux d'accès: Basic, Premium et Full. Nous attribuons ces niveaux aux groupes standard, administrateur et vice-présidents, respectivement. Cette opération s'effectue dans l'onglet Valeurs de groupe de la même section. Pour en savoir plus, consultez la section Attribuer des valeurs aux groupes d'utilisateurs de la documentation Attributs utilisateur.
L'ordre de ces règles étant important, nous voulons placer les valeurs d'accès les plus élevées en haut de la liste, pour remplacer les valeurs d'accès inférieures vers le bas. Pour en savoir plus sur ce comportement, consultez la page de documentation Attributs utilisateur.
Filtrer les données de ligne avec des attributs utilisateur
Imaginons qu'une exploration soit déjà en cours de création et qu'elle contienne toutes les informations de vente. Nous vérifierons le niveau d'accès de l'utilisateur qui envoie une requête à l'exploration ; si le niveau d'accès est Basic (que nous avons donné à tous nos commerciaux standard), nous filtrons toujours l'exploration en fonction du nom de l'utilisateur, afin que seuls les propres lignes de chaque vendeur soient accessibles. Si le niveau d'accès est Premium ou Complet, la requête ne sera pas filtrée. Par défaut, nous disposons d'un attribut utilisateur appelé Nom, qui correspond au nom de l'utilisateur Looker. Le code LookML de l'exploration se présente comme suit:
explore: sales_info {
sql_always_where: {% if {{_user_attributes['access_level']}} == "Basic" %}
${sales_info.name} = "{{_user_attributes['name']}}"
% endif %
;;
}
Filtrer les données de colonne à l'aide d'attributs utilisateur
Enfin, nous souhaitons masquer, dans le modèle financier, certaines colonnes d'informations permettant d'identifier personnellement l'utilisateur. Pour ce faire, nous pouvons utiliser les attributs utilisateur que nous avons créés, ainsi que les instructions pour appliquer des autorisations au niveau de la base de données dans Looker sur la page de documentation Attributs utilisateur, afin de n'accorder l'accès aux champs d'informations personnelles qu'aux utilisateurs disposant d'un niveau d'accès complète.
Et c'est fini ! Nous avons fini de configurer les contrôles d'accès au contenu et aux données, et tous nos utilisateurs sont libres d'explorer Looker. Ainsi, nous serons certains qu'ils ne verront que le contenu que nous leur avons autorisé à consulter.