Bonnes pratiques de sécurité pour l'analyse intégrée

Avec les analyses intégrées Looker, vous pouvez permettre à vos utilisateurs et à vos clients d'explorer les données intégrées dans un cadre iFrame à partir de n'importe quelle page Web, portail ou application au format HTML. L'iFrame exécute l'intégralité de l'application Looker, ne demandant que les données nécessaires à l'affichage de votre requête. Par conception, un iFrame n'est pas autorisé à lire ni à écrire des données sur votre site Web ou votre application externe.

L'intégration de données peut parfois poser des problèmes de confidentialité ou de sécurité. Pour limiter ce risque, nous recommandons aux administrateurs Looker de suivre ces bonnes pratiques:

  • Si vous intégrez du contenu Looker à des clients, configurez le contenu client sur une instance Looker distincte de celle que vous utilisez pour les analyses internes.
  • Ne connectez les données à l'instance intégrée Looker que si elles doivent être accessibles aux utilisateurs intégrés, qui peuvent être le public.
  • Protégez les jetons aléatoires dans les URL d'intégration publiques comme s'il s'agissait d'identifiants utilisateur, et désactivez les URL publiques si elles ne sont pas utilisées.
  • La valeur external_user_id attribuée doit être unique pour chaque ensemble d'autorisations, d'attributs utilisateur et de modèles donné. Assurez-vous de ne pas utiliser la même external_user_id pour différentes sessions d'intégration pour différents utilisateurs interactifs, et de ne pas utiliser la même external_user_id pour un seul utilisateur disposant d'autorisations, de valeurs d'attributs utilisateur ou d'accès au modèle différents.
  • Activez un système fermé.
  • Protégez le secret d'intégration signé comme s'il s'agissait d'identifiants administrateur pour votre instance Looker intégrée, et laissez l'intégration signée désactivée si vous ne l'utilisez pas.
  • Utilisez une authentification forte pour vos instances intégrées Looker (intégration signée, SAML, OAuth Google, authentification à deux facteurs).
  • Si vous utilisez l'intégration sans cookie, protégez le jeton de référence de session afin qu'il ne soit accessible que sur le serveur hôte de l'application intégrée. Le jeton de référence de session ne doit jamais être exposé dans le navigateur.
  • Si vous utilisez l'intégration sans cookie et que vous définissez le domaine d'intégration autorisé lorsque vous acquérez la session sans cookie, ne faites jamais confiance à l'origine du navigateur de l'utilisateur de l'intégration. Maintenez toujours un mappage de l'utilisateur intégré à l'origine approuvée de l'utilisateur intégré sur le serveur d'application d'intégration.

Looker propose différents types de méthodes d'intégration en fonction du niveau d'authentification requis pour les utilisateurs accédant à vos données: public, privé et intégration signée. Avec l'une de ces méthodes, vous pouvez interagir avec l'iframe à l'aide de JavaScript.

Intégration publique

Lorsque l'option Accès public d'une présentation est activée,vous pouvez intégrer une visualisation ou un tableau de données dans un site Web externe à l'aide d'une balise iFrame HTML. Vous pouvez également partager publiquement l'URL de la présentation ou importer des données dans des applications de feuille de calcul Google ou Excel.

L'URL et l'URL d'intégration de la balise iframe contiennent un jeton aléatoire et ne peuvent pas être devinés. Toutefois, toute personne disposant de l'URL d'intégration peut accéder aux données, et aucun filtrage ni aucune restriction supplémentaire ne sont appliqués. Nous vous recommandons de prendre en compte les implications de sécurité liées à la création et au partage d'une URL publique pour une présentation donnée avant d'activer les URL publiques.

Les URL publiques et les URL d'intégration publiques n'expirent jamais et ne peuvent pas être révoquées. Lorsque vous partagez une URL publique, vous partagez la requête,et non les données.

Incorporation privée

Si vous ne souhaitez pas autoriser l'accès public à votre présentation, vous pouvez également intégrer une présentation (ou une exploration ou un tableau de bord) de manière privée dans un iframe, de sorte qu'une connexion Looker soit requise pour afficher le contenu.

Les utilisateurs authentifiés ne peuvent accéder qu'au contenu dicté par les autorisations Looker qui leur sont attribuées. Si vous modifiez leurs autorisations dans Looker, l'URL d'intégration ne change pas, mais ce que l'utilisateur est autorisé à voir lorsqu'il accède à l'URL peut changer.

Si l'utilisateur n'est pas authentifié, vous pouvez afficher un message d'erreur ou un écran de connexion dans l'iFrame. Toutefois, l'activation d'un écran de connexion dans l'iFrame n'est pas compatible avec les protections de même origine de Looker.

Les URL d'intégration privées n'expirent jamais et ne peuvent pas être révoquées. Toutefois, comme le lien ne fonctionne que pour une personne ayant accès à votre instance Looker et à ces données, l'envoi d'un lien ne devrait pas poser de problème de sécurité.

Intégration signée

Veuillez contacter un spécialiste commercial Google Cloud pour mettre à jour votre licence pour cette fonctionnalité.

L'encapsulation signée va encore plus loin que l'encapsulation privée. L'intégration avec signature ne nécessite pas que les utilisateurs s'authentifient à l'aide d'un compte utilisateur Looker. Ils peuvent être authentifiés via votre propre application à l'aide de l'URL dans un iFrame. L'authentification crée une session de navigateur et émet un cookie dans le navigateur.

Les autorisations, les identifiants et les attributs des utilisateurs sont tous transmis en tant que paramètres dans l'URL, qui est signée avec une clé secrète. Toute personne ayant accès à la clé secrète peut créer une URL pour accéder à n'importe quel modèle auquel l'instance Looker est connectée, en tant qu'utilisateur, avec n'importe quelle autorisation. Consultez notre exemple de code pour découvrir comment générer des URL signées.

Le détournement de clic est un problème de sécurité du navigateur qui peut se produire lorsqu'un code intégré ou un script exécute une fonction à l'insu ou sans le consentement de l'utilisateur, par exemple un bouton qui semble effectuer une autre action. Le hameçonnage de clics nécessite généralement une URL statique. L'URL générée pour une intégration signée est secrète et ne doit être accessible qu'à l'utilisateur qui la consulte. L'utilisation de l'intégration avec signature n'augmente pas le risque de hameçonnage de clics sur le site Web externe.

Paramètres d'intégration signés

Les paramètres inclus dans l'URL de l'iFrame sont visibles par les utilisateurs qui l'intègrent, mais ne peuvent pas être modifiés. Les points pris en compte incluent :

  • user_attributes: ils permettent de filtrer davantage les données. Les user_attributes sont puissants. Réfléchissez à la façon dont ils peuvent s'appliquer à votre instance Looker.
  • session_length: limitez cette durée au minimum nécessaire.

Certains paramètres, tels que user_attributes, peuvent être masqués dans l'interface utilisateur, mais ils sont toujours encodés dans l'URL d'intégration. Cela peut être indésirable si, par exemple, un mot de passe est une valeur dans l'user_attribute d'un utilisateur. Pour contourner ce problème, vous pouvez créer un groupe temporaire, définir le mot de passe comme attribut au niveau du groupe, puis transmettre l'ID du groupe dans l'URL d'intégration. Vous pouvez supprimer le groupe après la session d'intégration pour éviter un excès de groupes expirés.

La partie signée de l'URL contient un code temporel. Une fois l'URL utilisée pour se connecter, cette heure doit être comprise entre +/- 5 minutes de l'heure actuelle. Dans session_length, vous pouvez spécifier la durée de la session d'intégration à partir du moment où l'URL est utilisée pour se connecter.

Gérer l'accès aux composants intégrés signés

Lorsque vous créez l'URL de votre contenu intégré:

  • Utilisez le niveau d'autorisations le plus bas possible.
  • N'attribuez l'accès qu'aux modèles spécifiques auxquels l'utilisateur doit pouvoir accéder.
  • Utilisez group_ids pour attribuer un utilisateur à un groupe et autoriser l'utilisateur intégré à contrôler l'accès à son dossier Looker.

API Looker

L'API Looker vous permet d'activer l'accès au contenu intégré à l'aide d'une application de proxy ou d'un serveur proxy inverse. Dans ce scénario, l'authentification s'effectue à l'aide de clés API, qui sont liées à un utilisateur spécifique et disposent des mêmes autorisations que celui qui les génère. Les clés API sont composées d'un ID client et d'une clé secrète client.

Gérer l'accès à l'intégration à l'aide de l'API

Lorsque vous activez l'accès au contenu intégré à l'aide de l'API Looker, nous vous recommandons:

  • Créer des comptes de service dédiés pour l'accès aux API de manière programmatique avec l'ensemble minimal d'autorisations nécessaires.
  • Protéger l'ID client et le secret client qui constituent la clé API (si l'authentification s'effectue avec un SDK).

Tous les attributs utilisateur définis pour les utilisateurs d'intégration à l'aide de l'API, mais non spécifiés dans l'URL d'intégration signée, sont réinitialisés à leurs valeurs par défaut lors de l'accès suivant à l'URL d'intégration signée.

Événements JavaScript intégrés

Une fois que vous avez configuré votre iFrame d'intégration (publiquement, en privé, avec une intégration signée ou via l'API), vous pouvez interagir avec cette iFrame à l'aide de JavaScript. Pour vérifier que les informations que vous utilisez proviennent bien de l'iFrame de Looker, vous pouvez écouter les événements JavaScript.

Lorsque vous ajoutez des domaines à la liste d'autorisation, utilisez le caractère générique pour n'autoriser que des sous-domaines spécifiques à accéder à vos événements JavaScript.

Si vous utilisez la fonction JavaScript eval, assurez-vous que la valeur de la chaîne dans l'argument eval provient d'une source fiable, telle que le serveur Looker ou le CDN, et qu'elle est transmise via le protocole HTTPS.

Aucune donnée client ne passe jamais par les CDN Looker. Seuls les éléments statiques de l'application Web Looker (code JavaScript, pages HTML, styles CSS) sont diffusés à partir d'un CDN.

Déploiements hébergés par le client

Héberger votre propre instance Looker peut sembler être la solution idéale pour verrouiller l'accès aux données, en particulier aux contenus intégrés. Toutefois, si vos utilisateurs doivent accéder à l'URL d'intégration via Internet, il n'y a aucun avantage particulier à héberger vous-même Looker.

Les déploiements hébergés par le client sont particulièrement adaptés dans les cas suivants:

  • Vos utilisateurs n'ont pas besoin d'accéder à Looker via Internet.
  • Vous utilisez Looker comme interface et accédez au contenu intégré à l'aide de l'API.