Configuration de la surveillance des utilisateurs finaux

Modifier en ligne

Contrairement à d'autres types de données de surveillance, telles que les données relatives à l'infrastructure ou aux applications, les données de surveillance des utilisateurs finaux sont toujours collectées à partir d'appareils non fiables connectés à Internet ou à un intranet local. C'est pourquoi il est nécessaire de procéder à des étapes de configuration supplémentaires afin de garantir que les navigateurs Web et les appareils mobiles des utilisateurs finaux puissent établir une connexion sécurisée en utilisant un nom de domaine public géré par votre organisation. Veillez également à ce que les utilisateurs finaux n'aient accès qu'au point de terminaison de surveillance qui leur est spécifiquement destiné, et non à d'autres éléments de l'infrastructure de surveillance.

Les sections suivantes expliquent le nœud final de surveillance approprié, les API exposées, les considérations de sécurité et la manière de mettre le nœud final de surveillance à la disposition de vos utilisateurs finaux.

Nœud final de surveillance

Modifier en ligne

Le backend d' Instana hébergé en local (sur site) de l' Instana expose les points de terminaison de surveillance des utilisateurs finaux HTTP sur les ports 86 ( HTTP ) et 446 ( HTTPS ). Ces ports peuvent être rendus accessibles sur Internet ou sur l'intranet, que ce soit directement ou via un proxy inverse, afin de permettre le téléchargement de l'agent JavaScript et la réception des données. Le nombre de ces ports est volontairement réduit au minimum afin de réduire les vecteurs d'attaque possibles et de permettre un déploiement simple du noeud final de surveillance.

Les ports et n'ont 80 délibérément 443 pas été utilisés, car ils sont réservés à l'accès à l'interface utilisateur d' Instana. En séparant la collecte des données et l'interface utilisateur, il devient plus facile de déployer en toute sécurité la solution de surveillance des utilisateurs finaux d' Instana.

Les requêtes HTTP sont acceptées sur 86 et 446 (proxy vers le port interne 2999) pour les chemins suivants :

Acceptation des données de surveillance du site
- GET /eum/
- POST /eum/
Téléchargement de l'agent JavaScript
- GET /eum/eum.min.js
- GET /eum/eum.min.js.map
- GET /eum/eum.js
- GET /eum/eum.js.map
- GET /eum/eum.debug.min.js
- GET /eum/eum.debug.min.js.map
- GET /eum/eum.debug.js
- GET /eum/eum.debug.js.map
Acceptation des données de surveillance de l'application mobile
- POST /eum/mobile

Dans l'interface utilisateur d' Instana, il est recommandé d'utiliser l'adresse URL comme point de terminaison trackingBaseUrl de surveillance. Une valeur valide pour trackingBaseUrl peut être https://*instanaServer*:446/eum/.

Exposer le nœud final de surveillance aux utilisateurs finaux

Modifier en ligne

Il est recommandé de mettre le point de terminaison de surveillance à la disposition des utilisateurs finaux à l'aide d'un proxy inverse, tel que NGINX, Apache ou HTTPd. Ce faisant, vous pouvez vous assurer que le trafic est correctement acheminé depuis Internet ou l'intranet via vos réseaux vers le noeud final de surveillance. De plus, cela vous permet de rendre accessible le point de terminaison de surveillance sous votre nom de domaine, via un 443 port utilisant le protocole TLS (TLS), vos propres certificats et des équilibreurs de charge (le cas échéant)! Toutefois, vous pouvez décider d'autoriser l'accès aux ports 86 et 446 directement à partir d'Internet.

Des exemples exécutables sont fournis pour montrer comment configurer des proxys inverses pour le noeud final de surveillance. Ces exemples montrent également quels en-têtes doivent être ajoutés ou mis en proxy, par exemple la nécessité d'un en-tête X-Forwarded-For .

NGINX en tant que proxy inverse

Remarque : ne modifiez pas la configuration de l' NGINX, qui est installé automatiquement lors de la configuration du backend Instana en mode auto-hébergé (sur site). Cette NGINX permet d'accéder à l'interface utilisateur de Instana et à API; elle est donc soumise à des exigences de sécurité et à des cycles de mise à jour différents. Plus précisément, la configuration de l' NGINX pourrait être écrasée lors des mises à jour ultérieures du backend Instana auto-hébergé (sur site) d' Instana. Cela peut facilement conduire à une configuration non sécurisée qui permet aux utilisateurs finaux d'accéder à l'écran de connexion d' Instana, aux API et aux ressources.

Veillez à configurer le point de terminaison de surveillance dans Instana, comme décrit dans les paramètres de surveillance des utilisateurs finaux (EUM), afin que l'interface utilisateur d' Instana puisse fournir des instructions d'installation correctes pour l'agent d' JavaScript et l'agent d'application mobile.

Configuration d'une connexion sécurisée entre les navigateurs et le proxy inverse

Modifier en ligne

Il est recommandé d'exposer le noeud final de surveillance avec le port HTTPS . Vous pouvez configurer la sécurité au niveau de la couche de transport ( TLS ) pour votre réseau sous le même nom de domaine à l'aide de certificats signés valides.

Si vous n'avez pas d'autorité de certification mais que vous utilisez des certificats autosignés , vous devez configurer un proxy inverse ou un équilibreur de charge pour effectuer des demandes de proxy sur les sites Web surveillés et sur le noeud final de surveillance, et configurer le proxy avec vos certificats autosignés.

Par exemple, vous configurez le proxy avec deux emplacements https://proxy-server/website et https://proxy-server/eum/. Ensuite, si l'utilisateur final accepte le certificat autosigné entrant pour https://proxy-server, ce certificat fonctionne à la fois pour les sites Web et pour le noeud final de surveillance.

Pour plus d'informations sur la génération de vos propres certificats autosignés, voir la documentation d'installation.

Base de données GeoLite2

Modifier en ligne

Instana utilise les bases de données GeoLite2 d' Maxmind pour prendre en charge la géolocalisation par adresse IP des données de surveillance des utilisateurs finaux. Maxmind vous oblige à mettre à jour régulièrement votre base de données GeoLite2 afin de vous conformer à la loi californienne sur la protection de la vie privée des consommateurs (CCPA). Sans cela, il manque des informations géographiques.

Pour configurer la base de données URL d' GeoLite2. dans l'édition Classic, procédez comme suit :

Téléchargez la base de données GeoLite2 , telle que https://packages.instana.io , en exécutant la commande suivante:
```
instana geodb download -k <agentKey>
 
```
Mettre à jour la base de données utilisée en interne.
```
instana geodb update -f <path/to/file>
 
```

Appliquez les modifications.

instana update -f /path/to/settings.hcl

Veillez à respecter le CLUFGeoLite2.

Analyse des problèmes

Modifier en ligne

Pour analyser un problème, procédez comme suit:

Ouvrez l'URL à l'agent JavaScript manuellement dans le navigateur. Est-ce que vous obtenez JavaScript comme réponse du serveur ?
- En cas d'échec et si vous utilisez un proxy, gardez à l'esprit que le chemin d'accès au fichier JavaScript est probablement modifié. Avec les exemples de configuration de proxy ci-dessus, le chemin d'accès est /eum.min.js. Si vous utilisez un proxy pour eum-acceptor sous un sous-chemin, vérifiez si vous prenez en compte les barres obliques de fin, c'est-à-dire, votre proxy utilise-t-il le chemin /eum ?
- Si cela échoue et que vous n'utilisez pas de proxy, n'oubliez pas que le point de terminaison de surveillance de l' Instana ne se connecte qu'aux ports 86 et 446.
- Si cela ne fonctionne toujours pas, contactez le support et expliquez la configuration, envoyez la configuration du proxy et expliquez comment vous essayez d'accéder au script.
Ajoutez le fragment de surveillance du site Web à votre application.
- Si vous ne voyez pas de données de site Web, utilisez le script de débogage de site Web. Au lieu d'accéder à eum.min.js, utilisez eum.debug.js. Cela consigne un ensemble d'informations sur la configuration et la transmission à la console du navigateur. Inspecter la console et résoudre d'autres problèmes.
- Ouvrez l'explorateur de réseau dans votre navigateur (il figure dans les outils de développement). Vous pouvez voir les appels HTTP GET et HTTP POST sortants vers l' URL de rapport configurée. Assurez-vous que ces appels renvoient un code de statut 200 ou 204. Veillez tout particulièrement à ce que le proxy ne renvoie aucune redirection de type « HTTP » (code d'état 302 ) à la suite de cet appel.
- Si cela ne fonctionne toujours pas, contactez le support et expliquez la configuration, envoyez la configuration du proxy, expliquez comment vous essayez d'accéder au script et envoyez la sortie du script de débogage.