Bonnes pratiques de sécurité pour les analyses intégrées

Grâce à l'analyse intégrée de Looker, vous pouvez permettre à vos utilisateurs et clients d'explorer les données intégrées dans un iFrame dans n'importe quelle page Web, portail ou application au format HTML. L'iFrame exécute l'ensemble de l'application Looker et ne demande que les données nécessaires à l'affichage de votre requête. Par conception, un iFrame n'est pas autorisé à lire ou à écrire des données sur votre site Web ou votre application externes.

L'intégration de données peut parfois entraîner des problèmes de confidentialité ou de sécurité. Pour atténuer ces problèmes, nous recommandons aux administrateurs Looker de suivre ces bonnes pratiques:

  • Si vous intégrez du contenu Looker aux clients, configurez le contenu client sur une instance Looker distincte de l'instance que vous utilisez pour les analyses internes.
  • Ne connectez que les données à l'instance Looker intégrée qui devraient être accessibles aux utilisateurs de l'intégration, 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 d'autorisations, attributs utilisateur et modèles. Assurez-vous de ne pas utiliser le même external_user_id pour différentes sessions d'intégration pour différents utilisateurs interactifs, et de ne pas utiliser le même external_user_id pour un même utilisateur disposant d'autorisations, de valeurs d'attributs utilisateur ou d'accès au modèle différents.
  • Activer un système fermé
  • Protégez le code secret d'intégration de l'authentification unique comme s'il s'agissait d'identifiants administrateur pour votre instance Looker intégrée et désactivez l'intégration de l'authentification unique si vous ne l'utilisez pas.
  • Utilisez une authentification forte pour vos instances Looker intégrées (SSO, SAML, Google OAuth, 2FA).

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: accès public, accès privé et authentification unique. Vous pouvez interagir avec l'iFrame à l'aide de JavaScript.

Représentation vectorielle continue publique

Lorsque l'option Accès public d'un look 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 recherche 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. Toutefois, toute personne disposant de l'URL d'intégration peut accéder aux données, et aucun filtrage ou restriction supplémentaire n'est appliqué. Nous vous recommandons de prendre en compte les conséquences sur la sécurité de la création et du partage d'une URL publique pour un style donné avant d'activer les URL publiques.

Les URL publiques et les URL d'intégration publiques n'expirent pas 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.

Incorporation privée

Si vous ne souhaitez pas autoriser l'accès public à votre Look, vous pouvez également intégrer un Look (ou une exploration ou un tableau de bord) à un iFrame en mode privé, afin qu'une connexion Looker soit requise pour afficher le contenu.

Les utilisateurs authentifiés peuvent uniquement accéder 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 afficher un écran de connexion dans le cadre 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 pas et ne peuvent pas être révoquées. Toutefois, étant donné que le lien ne fonctionne que pour une personne qui a 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 d'authentification unique

Veuillez contacter votre responsable de compte pour mettre à jour votre licence pour cette fonctionnalité.

L'intégration de l'authentification unique va encore plus loin. L'intégration SSO n'exige pas des utilisateurs qu'ils s'authentifient via un compte utilisateur Looker. Ils peuvent être authentifiés via votre propre application via l'URL d'un iFrame. L'authentification crée une session de navigateur et envoie un cookie au navigateur.

Les autorisations, identifiants et attributs des utilisateurs sont 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 permettant d'accéder à n'importe quel modèle auquel une instance Looker est connectée, avec n'importe quel utilisateur. Consultez notre exemple de code pour découvrir comment générer des URL signées.

Le clickjacking est un problème de sécurité qui peut se produire lorsque le code intégré ou un script exécute une fonction à l'insu de l'utilisateur ou ne lui donne pas son consentement (par exemple, en appuyant sur un bouton qui semble effectuer une autre action). Le détournement de clic nécessite généralement une URL statique. L'URL générée pour une intégration SSO est secrète, et seul l'utilisateur qui l'affiche doit en avoir une. L'intégration de l'authentification unique n'augmente pas le risque de détournement de clics du site Web externe.

Paramètres d'intégration SSO

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

  • user_attributes: permet de filtrer davantage les données. Les user_attributes sont puissantes. Demandez-vous donc si elles peuvent s'appliquer à votre instance Looker.
  • session_length: limitez-vous à la durée minimale nécessaire.

Certains paramètres, comme user_attributes, peuvent être masqués dans l'interface utilisateur, mais sont toujours encodés dans l'URL d'intégration. Ce n'est pas souhaitable si, par exemple, un mot de passe est une valeur comprise dans la user_attribute d'un utilisateur. Pour contourner ce problème, vous pouvez créer un groupe temporaire, définir le mot de passe en tant qu'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 ponctuels.

La partie signée de l'URL contient un code temporel. Une fois l'URL utilisée, connectez-vous à l'heure indiquée, c'est-à-dire environ 5 minutes après l'heure actuelle. Vous pouvez spécifier dans session_length la durée maximale 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 SSO

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

  • Utilisez le niveau d'autorisation le plus faible nécessaire.
  • Attribuez uniquement l'accès aux modèles spécifiques auxquels l'utilisateur devrait avoir accès.
  • 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 de Looker vous permet d'activer l'accès au contenu intégré via une application de proxy ou un serveur proxy inverse. Dans ce scénario, l'authentification s'effectue via des clés API3. 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 API3 sont composées d'un ID client et d'une clé code secret du client.

Gérer l'accès aux intégrations via une API

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

  • La création de services dédiés permet d'accéder à l'API programmatique avec les privilèges minimaux requis.
  • Protection de l'ID client et du code secret du client qui composent la clé API3 (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 qui ne sont pas spécifiés dans l'URL SSO sont réinitialisés à leur valeur par défaut lors de leur prochain accès.

Événements JavaScript intégrés

Une fois que vous avez configuré votre iFrame intégré (en mode public, privé, avec l'authentification unique ou via l'API), vous pouvez interagir avec cet iFrame via JavaScript. Pour vérifier que les informations avec lesquelles vous travaillez 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 autoriser uniquement des sous-domaines spécifiques à accéder à vos événements JavaScript.

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

Aucune donnée client ne passe par les CDN Looker. Seuls les assets statiques des applications Web Looker (code JavaScript, pages HTML, styles CSS) sont diffusés à partir du CDN.

Déploiements hébergés par le client

Héberger votre propre instance Looker peut être le moyen le plus sûr de verrouiller l'accès aux données, en particulier au contenu intégré. Toutefois, si vos utilisateurs ont besoin d'accéder à l'URL d'intégration sur Internet, l'hébergement de Looker vous-même ne présente aucun avantage particulier.

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

  • Vos utilisateurs ne sont pas obligés d'accéder à Looker via Internet.
  • Vous utilisez Looker en tant qu'interface et accédez au contenu intégré via l'API.