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

Avec 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 sur n'importe quelle page Web, n'importe quel portail ou n'importe quelle application au format HTML. L'iFrame exécute l'ensemble de l'application Looker et demande uniquement les données nécessaires pour afficher votre requête. Dès la conception, un iFrame n'est pas autorisé à lire ni à écrire des données à partir de votre application ou de votre site Web externe.

L'intégration de données peut parfois poser 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 à vos clients, configurez-le sur une instance Looker distincte de celle que vous utilisez pour les analyses internes.
• Connectez uniquement les données à l'instance intégrée Looker qui devraient être accessibles par les utilisateurs de l'intégration, qui peuvent être publics.
• Protégez les jetons aléatoires dans les URL publiques intégrées comme s'il s'agissait d'identifiants utilisateur et désactivez les URL publiques s'ils ne sont pas utilisés.
• Une valeur external_user_id attribuée doit être unique pour chaque ensemble donné d'autorisations, d'attributs utilisateur et de modèles. Vérifiez que vous n'utilisez pas le même external_user_id pour différentes sessions d'intégration pour différents utilisateurs interactifs, et que vous n'utilisez pas le même external_user_id pour un seul utilisateur disposant d'autorisations, de valeurs d'attribut utilisateur ou d'un accès au modèle différents.
• Activer un système fermé
• Protégez le secret d'intégration signé comme s'il s'agissait d'identifiants d'administrateur de votre instance Looker intégrée et laissez l'intégration signée désactivée si vous ne l'utilisez pas.
• Utilisez l'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 la 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 la session ne doit jamais être exposé dans le navigateur.
• Si vous utilisez une 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 dans le navigateur de l'utilisateur de l'intégration. Maintenez toujours un mappage de l'utilisateur de l'intégration sur son origine de confiance dans le serveur d'application intégré.

Looker propose différents types de méthodes d'intégration en fonction du niveau d'authentification requis des utilisateurs qui accèdent à vos données: publique, privée et intégrée signée. Quelle que soit 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 à 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 feuilles de calcul Google ou Excel.

L'URL et l'URL d'intégration dans la balise iframe contiennent un jeton aléatoire qui ne peut pas être deviné. Cependant, toute personne disposant de l'URL d'intégration peut accéder aux données, et aucun filtrage ni restriction supplémentaire n'est appliqué. Nous vous recommandons de réfléchir aux implications en termes de sécurité de la création et du partage d'une URL publique pour un Look donné avant d'activer les URL publiques.

Les URL publiques et les URL intégrées 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.

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) en mode privé dans un iFrame. Une connexion à Looker sera alors nécessaire 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 ses 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 intégrées privées n'expirent jamais et ne peuvent pas être révoquées. Toutefois, étant donné que 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é.

Représentation vectorielle continue signée

Veuillez contacter un spécialiste des ventes Google Cloud afin de mettre à jour votre licence pour cette fonctionnalité.

La représentation vectorielle continue signée va encore plus loin. L'intégration signée ne nécessite pas que les utilisateurs s'authentifient à l'aide d'un compte utilisateur Looker. À la place, ils peuvent être authentifiés via votre propre application en utilisant l'URL d'un iFrame. L'authentification crée une session de navigateur et envoie un cookie au navigateur.

Les autorisations, identifiants et attributs 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, comme n'importe quel utilisateur, avec n'importe quelle autorisation. Consultez notre exemple de code pour savoir comment générer des URL signées.

Le clickjacking 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 de l'utilisateur ou sans son consentement (par exemple, 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 signée est secrète, et seul l'utilisateur qui visualise l'ingestion doit l'avoir. L'utilisation d'une intégration signée n'augmente pas le risque de détournement de clic vers 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 intégrés, 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. Réfléchissez à la manière dont elles peuvent s'appliquer à votre instance Looker.
• session_length: limitez-vous au temps minimal nécessaire.

Certains paramètres, tels que user_attributes, peuvent être masqués dans l'interface utilisateur, mais ils restent 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 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 nombre excessif de groupes obsolètes.

La partie signée de l'URL contient un code temporel. Une fois que l'URL est utilisée pour se connecter, cette heure doit se situer à environ cinq 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 la connexion.

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

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

• Utilisez le plus petit niveau d'autorisation nécessaire.
• N'accordez l'accès qu'aux modèles spécifiques auxquels l'utilisateur doit avoir accès.
• Utilisez group_ids pour attribuer un utilisateur à un groupe et autoriser l'utilisateur de l'intégration à contrôler l'accès à son dossier Looker.

API Looker

À l'aide de l'API de Looker, vous pouvez autoriser 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 l'utilisateur 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 intégré à l'aide de l'API

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

• Créer des comptes de services dédiés pour l'accès programmatique aux API, avec l'ensemble minimal de droits nécessaires
• La protection de l'ID et du code secret du client qui constituent la clé API (en cas d'authentification avec un SDK)

Tous les attributs utilisateur définis pour les utilisateurs de l'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 au prochain accès à l'URL d'intégration signée.

Événements JavaScript intégrés

Une fois que vous avez configuré votre iFrame intégré (en mode public, privé, 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 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 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 chaîne dans l'argument eval provient d'une source fiable, telle que le serveur Looker ou le CDN, et qu'elle se trouve dans un transport 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 de CDN.

Déploiements hébergés par le client

Héberger votre propre instance Looker peut être un moyen 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 via 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 plus appropriés dans les cas suivants:

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