Bonne pratique: sécurisez vos dossiers. Tutoriel sur l'accès au contenu

Ces bonnes pratiques reflètent les recommandations partagées par une équipe interfonctionnelle de chercheurs expérimentés. Ces insights sont issus de nos années d'expérience auprès des clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour fonctionner pour la plupart des utilisateurs et des situations, mais comme toujours, utilisez votre bon sens lors de leur implémentation.

Cette page fournit aux administrateurs d'instances Looker un exemple guidé de configuration des contrôles d'accès au contenu. Nous allons passer en revue le processus d'implémentation, en commençant par un nouveau projet, puis en continuant avec 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 modèle est une pièce de la maison qui contient du contenu spécifique.

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és qui spécifie ce que les utilisateurs peuvent faire dans une pièce (manger, jouer, dormir, etc.).

Un groupe permet de regrouper des personnes qui présentent des caractéristiques communes (adultes, enfants, invités).

Un rôle permet de fournir à des groupes de personnes leurs checklists d'activités dans différents ensembles de salles.

Un attribut utilisateur est une clé qui permet d'accéder à des éléments spéciaux de la maison (théière, outils électriques).

Scénario

Voici un exemple de start-up avec des équipes chargées des finances, des ventes et des produits. La PDG est notre seule administrateur. Elle souhaite que chaque équipe ne voie que les contenus qui la concernent, à l'exception du vice-président de chaque équipe, qui doit avoir accès à tous les contenus. Elle souhaite accorder des droits d'accès différents aux employés standards, aux responsables et aux vice-présidents.

• Les employés standards doivent pouvoir afficher et explorer les données de leurs propres modèles.
• Les administrateurs doivent disposer d'un accès standard, et doivent également pouvoir télécharger et planifier du contenu.
• Les VP doivent disposer de presque tous les droits, à l'exception de quelques-uns réservés au PDG.

Le PDG souhaite que les commerciaux puissent consulter les données de leurs propres activités, mais pas celles des autres commerciaux. Toutefois, les responsables commerciaux doivent pouvoir consulter les chiffres de chaque vendeur. Enfin, certains champs financiers contenant des informations sensibles doivent être masqués pour les employés standards qui utilisent ce modèle.

Voici l'organigramme:

Ce graphique 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 Ouest
• Responsable commercial Est
• Commercial Est
• VP du département Produit
• Chef de produit
• Engineer

Pour implémenter les contrôles d'accès souhaités, procédez comme suit:

1. Créer un projet:un projet est le lien structurel entre une connexion de base de données et des modèles de données.
2. Ajouter des modèles:déterminez quelles données seront révélées à quels utilisateurs.
3. Créez des ensembles de modèles:regroupez les modèles pertinents.
4. Créer des ensembles d'autorisations:définissez explicitement les actions que les utilisateurs peuvent effectuer dans un ensemble de modèles.
5. Créer des groupes:regroupez les utilisateurs similaires.
6. Créer des rôles:créez les connexions entre les ensembles de modèles, les ensembles d'autorisations et les groupes.
7. Modifier l'accès aux contenus:gérez les tableaux de bord et les présentations que les utilisateurs peuvent consulter via des dossiers.
8. 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

La première chose dont nous avons besoin est un projet, qui est un conteneur pour un ou plusieurs modèles. Si vous avez déjà configuré un projet, vous pouvez ignorer cette étape. Vous pouvez également accéder à la page Projets LookML en sélectionnant Projets dans la section Développer de Looker, puis Nouveau projet LookML pour créer un projet. Pour obtenir des instructions plus détaillées sur la création d'un projet, consultez la page de documentation Générer un modèle.

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 Point de départ, nous sélectionnons Générer un modèle à partir du schéma de base de données.
• Dans le menu déroulant Connection (Connexion), nous sélectionnons le nom de notre connexion à la base de données.
• Dans la section Créer des vues à partir de, pour cet exemple, nous sélectionnons l'option 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 les paramètres souhaités pour le nouveau projet configurés, nous sélectionnons Create Project (Créer un projet).

Lorsque vous créez un projet, vous êtes redirigé vers le modèle LookML généré automatiquement pour ce projet. À ce stade, vous devez utiliser le bouton Configurer Git pour configurer le contrôle des versions du 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 modèle de données est comme un portail personnalisable dans la base de données. chacun d'eux pouvant présenter des données différentes d'un utilisateur à l'autre. 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 pour exposer les informations appropriées de la base de données à chaque type d'utilisateur.

Dans notre projet LookML, nous allons ajouter de nouveaux fichiers de modèle LookML avec le nom 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 d'ensembles de modèles (sinon, ils ne s'afficheront 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 de documentation 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, revenez à la page Projects (Projets) dans la section Develop (Développer). Le texte rouge "Configuration requise pour l'utilisation" devrait maintenant s'afficher à côté de chaque nom de modèle.

À côté de chaque modèle, sélectionnez Configurer. Nous nous assurerons que le nom du projet est correct, ainsi que les connexions que nous autoriserons ce modèle à utiliser, puis nous enregistrerons.

Une fois tous les modèles correctement configurés, les messages de problème de configuration en rouge que nous rencontrions précédemment n'apparaîtront plus.

N'oubliez pas que dans Looker, si vous accordez à un utilisateur l'autorisation see_lookml ou develop pour un modèle, il dispose de cette autorisation pour tous les modèles de ce projet. Par conséquent, vous devez créer des projets distincts si vous souhaitez partitionner les autorisations de consultation ou de développement de LookML. Sinon, créez simplement un autre modèle. Les autorisations de 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 nouveaux ensembles de modèles créés, ils s'affichent dans la section Ensembles de modèles de la page Rôles, comme illustré dans l'exemple de capture d'écran suivant:

4. Créer des ensembles d'autorisations

Nous allons ensuite 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 quatre niveaux d'autorisations correspondant aux quatre niveaux hiérarchiques de l'organigramme. Les niveaux supérieurs doivent inclure les autorisations des niveaux inférieurs. Dans notre scénario, nous identifierons les ensembles d'autorisations comme suit:

• L'autorisation Administrateur est définie pour le PDG.
• Les VP disposent de l'autorisation Administrateur limité.
• L'autorisation Télécharger et partager est définie pour les administrateurs.
• Les employés standards disposent de l'autorisation Afficher et explorer.

Pour créer des ensembles d'autorisations, accédez à la page Rôles du panneau Administration, puis sélectionnez Nouvel ensemble d'autorisations. Pour chaque niveau d'autorisation, nous sélectionnerons les autorisations appropriées. En général, les ensembles d'autorisations doivent se chevaucher le moins possible, et chaque ensemble ne doit ajouter que les autorisations spécifiques que nous souhaitons que les utilisateurs disposant de cet ensemble d'autorisations aient. En effet, nous allons attribuer plusieurs ensembles d'autorisations à certains utilisateurs, et nous voulons savoir exactement ce que chacun d'eux permet. Toutefois, en raison de la structure arborescente, un certain chevauchement est souvent nécessaire.

Dans notre exemple, nous souhaitons que l'autorisation Afficher et explorer soit définie pour permettre aux utilisateurs d'afficher du contenu, de poser des questions et d'enregistrer des cartes utiles. Nous leur accordons donc les autorisations associées à l'affichage de 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 réserver aux développeurs, et see_sql, que nous réservons à ceux qui comprennent SQL et qui sont autorisés à afficher la structure de la base de données. Toutes ces autorisations sont strictement sous la branche access_data. Nous n'accordons aucune des autorisations see en bas de l'arborescence, car il s'agit d'autorisations administratives.

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 de partager des looks avec des utilisateurs qui ne sont pas des Lookers) et à see_schedules (puisqu'ils peuvent créer des planifications, il est logique qu'ils puissent également les afficher dans le panneau "Administration").

Les seuls champs sélectionnés lors de la configuration des ensembles d'autorisations Afficher et explorer et Télécharger et partager sont les autorisations parent requises pour sélectionner les autorisations enfant ajoutées sous la branche access_data. Par conséquent, comme les utilisateurs disposant de l'autorisation 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'autorisation Télécharger et partager, car elles ne contiennent aucune autorisation enfant requise pour l'autorisation Télécharger et partager.

Enfin, pour l'ensemble d'autorisations Administrateur limité, nous ajouterons la plupart des autorisations administratives en bas de l'arborescence, à l'exception des droits manage_models et sudo que la PDG ne souhaite que pour elle-même. Voici à quoi cela ressemble:

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_users et update_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_s3 et send_to_sftp.
• Afficher et explorer: l'ensemble d'autorisations Afficher et explorer inclut les autorisations access_data, create_table_calculations, explore, save_content, see_drill_overlay, see_lookml_dashboards, see_looks et see_user_dashboards.

Pour afficher les autorisations appartenant à un ensemble d'autorisations existant, accédez à la section Ensembles d'autorisations de la page d'administration Rôles.

5. Créer des groupes

L'étape suivante consiste à créer des groupes et à regrouper nos utilisateurs. 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 plus tard. Les vice-présidents seront dans leur propre groupe, et le PDG n'a pas besoin de groupe. Une fois l'opération terminée, la page Groupes doit afficher les groupes suivants et leurs ID de groupe correspondants, qui sont générés automatiquement par Looker. Exemple :

Une fois les groupes créés, nous devons 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, n'oubliez pas que, en raison de la façon dont nous avons structuré les autorisations, les groupes de niveau supérieur peuvent être inclus dans les groupes de niveau inférieur. Par exemple, nous voulons que les VP soient dans le groupe Finances, mais pas les responsables commerciaux dans le groupe Produit. Pour procéder efficacement, commencez par ajouter des utilisateurs aux groupes de niveau supérieur (comme les VP), afin de pouvoir les ajouter en tant que groupe aux niveaux inférieurs.

6. Créer des rôles

Maintenant que nous avons mis en place nos ensembles de modèles, nos ensembles d'autorisations et nos groupes, nous pouvons les rassembler à l'aide de rôles. Chaque rôle dispose d'un seul ensemble d'autorisations et d'un seul ensemble de modèles, et peut inclure un ou plusieurs groupes. Comme les rôles doivent inclure un ensemble de modèles, nous allons à nouveau créer des rôles pour les employés standards et les responsables de chaque service.

• Rôles standards: les rôles standards 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 aux groupes d'administrateurs de ce service, ainsi qu'au vice-président. Par exemple, attribuez le rôle Standard Finance aux groupes Finance et Finance Manager, ainsi qu'au vice-président des finances.
• Rôles d'administrateur:l'autorisation Télécharger et partager est définie pour les rôles d'administrateur, ainsi que le modèle correspondant. Ces rôles doivent être attribués au groupe des responsables du service correspondant et au vice-président du service.
• Rôles d'administrateur:l'autorisation Télécharger et partager est définie pour les rôles d'administrateur, ainsi que le modèle correspondant. Ces rôles doivent être attribués au groupe des responsables du service correspondant et au vice-président du service.
• Rôle de VP: le rôle de VP aura l'autorisation Administrateur limité définie et le modèle Tout défini. Ce rôle sera attribué au groupe VP.

7. Modifier l'accès au contenu

L'étape suivante consiste à organiser les autorisations d'accès aux dossiers afin que chaque groupe ait accès à ses propres contenus (et uniquement à ses propres contenus). Voici la mise en page des dossiers de notre exemple d'instance, que vous pouvez consulter 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 sur le fonctionnement de ce processus, 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 l'accès Afficher à tous les utilisateurs du dossier Partagé. Nous allons accorder à chaque groupe un accès Vue aux dossiers parents de l'arborescence au-dessus des dossiers auxquels le groupe aura accès. Ainsi, lorsque nous parcourons l'arborescence, si nous ne souhaitons pas qu'un groupe puisse voir un dossier, nous n'incluons pas ce groupe lorsque nous accordons 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 souhaitons contrôler les utilisateurs autorisés à le voir. Dans notre exemple, nous ne voulons que le PDG et les VP disposent de ces autorisations. Tous les autres utilisateurs n'auront qu'un accès en lecture aux dossiers dont ils ont besoin.

8. Ajouter des restrictions d'accès aux données avec des attributs utilisateur

Cette section présente des méthodes permettant d'empêcher des utilisateurs spécifiques d'accéder à des lignes ou 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. Les responsables commerciaux doivent toutefois pouvoir consulter les chiffres de chaque vendeur. Pour ce faire, nous allons utiliser les attributs utilisateur et le paramètre sql_always_where.

Créer des attributs utilisateur

Tout d'abord, nous allons créer un attribut utilisateur appelé access_level, qui sera masqué pour les utilisateurs. Cela nous permettra de définir des niveaux d'accès pour les différents groupes que nous avons. Nous définirons les valeurs suivantes lorsque nous créerons notre 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 laisserons la case Définir une valeur par défaut décochée.

Lors de la création du champ, nous allons configurer trois niveaux d'accès: Standard, Premium et Complet. Nous allons attribuer ces niveaux aux groupes standard, administrateur et directeur, respectivement. Pour ce faire, accédez à l'onglet Grouper les valeurs de la même section. Pour en savoir plus, consultez la section Attribuer des valeurs à des groupes d'utilisateurs de la documentation sur les attributs utilisateur.

Étant donné que l'ordre de ces règles est important, nous souhaitons placer les valeurs d'accès les plus élevées en haut de la liste, afin de remplacer les valeurs d'accès les plus faibles en bas. Ce comportement est expliqué plus en détail sur la page de documentation Attributs utilisateur.

Filtrer les données de ligne avec des attributs utilisateur

Imaginons qu'une exploration est déjà en cours de création avec toutes les informations sur les ventes. Nous vérifierons le niveau d'accès de l'utilisateur qui interroge l'exploration. Si le niveau d'accès est Standard (que nous avons attribué à tous nos vendeurs standards), nous filtrerons toujours l'exploration en fonction du nom de l'utilisateur. Ainsi, seuls les vendeurs pourront accéder à leurs propres lignes. Si le niveau d'accès est Premium ou Complet, la requête n'est 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 avec des attributs utilisateur

Enfin, certaines colonnes du modèle financier contiennent des informations permettant d'identifier personnellement les utilisateurs que nous souhaitons également masquer pour certains d'entre eux. Pour ce faire, nous pouvons utiliser les attributs utilisateur que nous avons créés, ainsi que les instructions d'application des autorisations au niveau de la base de données dans Looker sur la page de documentation Attributs utilisateur, afin de n'autoriser que les utilisateurs disposant du niveau d'accès Full (Complet) à voir les champs d'informations personnelles.

Et c'est terminé ! Nous avons terminé de configurer nos contrôles d'accès aux contenus et aux données. Tous nos utilisateurs peuvent désormais explorer Looker. Nous pouvons ainsi nous assurer qu'ils ne verront que les contenus que nous leur avons autorisés à consulter.