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

Avec l'analyse intégrée de Looker, vous pouvez permettre aux utilisateurs et aux clients d'explorer les données intégrées dans un iFrame à partir de n'importe quelle page Web, application ou portail au format HTML. L'iFrame exécute l'application Looker complète et ne demande que les données nécessaires pour afficher votre requête. De par sa conception, un iFrame n'est pas autorisé à lire ou à é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 l'analyse interne.
  • Ne connectez que les données à l'instance Looker intégrée qui doivent être accessibles aux utilisateurs intégrés, qui peuvent être publics.
  • 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.
  • Une valeur external_user_id attribuée doit être unique pour chaque ensemble donné d'autorisations, d'attributs utilisateur et de modèles. Assurez-vous de ne pas utiliser le même external_user_id dans différentes sessions d'intégration pour différents utilisateurs interactifs, et de ne pas utiliser le même external_user_id pour un seul utilisateur disposant d'autorisations, de valeurs d'attribut 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 d'administrateur pour votre instance Looker intégrée, et désactivez l'intégration signée si vous ne l'utilisez pas.
  • Utilisez une authentification forte pour vos instances Looker intégrées (intégration signée, SAML, Google OAuth, A2F).
  • 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 d'intégration. 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é lors de l'acquisition de la session sans cookie, ne faites jamais confiance à l'origine du navigateur de l'utilisateur intégré. Conservez toujours un mappage de l'utilisateur intégré vers 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 : publique, privée et 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 une table 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 dans la balise iframe contiennent un jeton aléatoire et ne peuvent pas être devinées, mais toute personne disposant de l'URL d'intégration peut accéder aux données, et aucun filtrage ni restriction supplémentaires ne sont appliqués. Nous vous recommandons de tenir compte des implications en termes 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 réelles.

Intégration privée

Si vous ne souhaitez pas autoriser l'accès public à votre présentation, vous pouvez également intégrer une présentation, 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 une 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 des ventes Google Cloud pour mettre à jour votre licence pour cette fonctionnalité.

L'intégration signée va encore plus loin que l'intégration privée. Elle ne nécessite pas que les utilisateurs s'authentifient à l'aide d'un compte utilisateur Looker. Au lieu de cela, 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 de l'utilisateur 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 sans que l'utilisateur le sache ou y consente, par exemple un bouton qui semble faire autre chose. Le détournement de clic nécessite généralement une URL statique. L'URL générée pour une intégration signée est secrète, et seul l'utilisateur qui affiche l'intégration doit y avoir accès. L'utilisation de l'intégration signée n'augmente pas le risque de détournement de clic sur le site Web externe.

Paramètres d'intégration signée

Les paramètres inclus dans l'URL de l'iFrame sont visibles par les utilisateurs intégrés, mais ne sont pas modifiables. Les points pris en compte incluent :

  • user_attributes : ils permettent de filtrer davantage les données. user_attributes sont puissants. Réfléchissez donc à la manière dont ils peuvent s'appliquer à votre instance Looker.
  • session_length : limitez-la au minimum nécessaire.

Certains paramètres, tels que user_attributes, peuvent être masqués dans l'interface utilisateur, mais ils seront 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 le 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 de 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 à +/- 5 minutes de l'heure actuelle. Vous pouvez spécifier dans session_length 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 à l'intégration signée

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

  • Utilisez le niveau d'autorisations le plus bas possible.
  • N'accordez 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 permettre à l'utilisateur intégré de 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. Celles-ci 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é code secret du 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 de procéder comme suit :

  • Créez des comptes de service dédiés pour l'accès à l'API par programmation avec l'ensemble minimal de privilèges nécessaires.
  • Protégez l'ID client et le code secret du client qui composent la clé API (si vous vous authentifiez avec un SDK).

Tous les attributs utilisateur définis pour les utilisateurs intégrés à l'aide de l'API, mais non spécifiés dans l'URL d'intégration signée, sont rétablis à leurs valeurs par défaut lors du prochain accès à 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, de manière privée, avec une intégration signée ou via l'API), vous pouvez interagir avec cet iFrame à l'aide de JavaScript. Pour vérifier que les informations que vous utilisez proviennent réellement 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 autoriser uniquement des sous-domaines spécifiques à accéder à vos événements JavaScript.

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

Aucune donnée client ne transite 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 du CDN.

Déploiements hébergés par le client

L'hébergement de votre propre instance Looker peut sembler être le moyen infaillible de verrouiller l'accès aux données, en particulier au contenu intégré. Toutefois, si vos utilisateurs doivent accéder à l'URL d'intégration sur Internet, l'hébergement de Looker ne présente aucun avantage particulier.

Les déploiements hébergés par le client peuvent être plus appropriés dans les cas suivants :

  • Vos utilisateurs ne sont pas tenus d'accéder à Looker via Internet.
  • Vous utilisez Looker en façade et accédez au contenu intégré à l'aide de l'API.