Explorer le réseau privé virtuel (VPN)

Utilisez un réseau VPN pour intégrer votre instance à des sources de données externes sur Internet.

Lors de la configuration d’une intégration qui utilise un protocole chiffré, tel que LDAP (Lightweight Directory Access Protocol) ou HTTPS, il est recommandé d’utiliser Internet comme mécanisme de transport.

Cependant, il peut y avoir des exigences de sécurité ou d’architecture réseau qui dictent l’utilisation d’une connexion de réseau privé virtuel (VPN) de sécurité de protocole Internet (IPSEC) de site à site entre les centres de données et vos réseaux d’entreprise. Le VPN prend en charge la communication chiffrée nécessaire entre l’instance et votre réseau.

Avertissement :

Lorsqu’un tunnel VPN est initié, il fonctionne comme une connexion de site à site. Cela signifie que le point de terminaison de votre infrastructure reçoit une adresse IP, appelée domaine de chiffrement. Cette adresse IP publique est accessible par n’importe quelle instance au sein d’un même centre de données.

Par exemple, si vous disposez d’un service Web interne et que vous établissez un tunnel VPN, votre instance est en mesure d’atteindre le point de terminaison interne ainsi que toutes vos autres instances dans le même centre de données.

Connexions VPN

L’infrastructure ServiceNow VPN utilise des paires d’appareils Cisco Adaptive Security Appliance (ASA) qui servent de points de terminaison VPN.

Le VPN entre l’instance et votre réseau utilise votre matériel réseau existant pour prendre en charge les communications. Il n’est pas nécessaire d’installer un matériel. Étant donné que chaque client dispose d’une configuration unique, l’instance dispose d’une solution VPN flexible. l’instance a créé des tunnels vers Checkpoint, Juniper, Nortel et d’autres appareils compatibles VPN IPSEC.

Les connexions VPN entre l’instance et votre réseau sont créées pour prendre en charge le flux chiffré du trafic dans votre réseau. Souvent, les intégrations qui utilisent le VPN n’ont pas de cryptage dans le cadre du protocole sous-jacent. Par exemple, LDAP sur le VPN par rapport à LDAPS sur Internet et HTTP sur le VPN par rapport à HTTPS sur Internet.

Le réseau n’autorise aucun trafic entrant vers l’intégration ServiceNow ou d’utilisateur final vers ServiceNow à traverser une connexion VPN. Cette communication restreinte comprend l’accès de l’utilisateur final à la plateforme, l’administration de la plateforme, les intégrations de services Web et d’autres intégrations configurées pour utiliser un serveur MID. Toutes ces communications entrantes vers l’instance doivent être effectuées via Internet à l’aide du protocole HTTPS. Cette configuration fournit un canal de communication chiffré. Le canal de chiffrement, ainsi que le contrôle d’accès IP, répondent aux exigences de sécurité pour ce flux de trafic.

Adresses pour la communication VPN

Pour éviter les conflits ou les chevauchements avec les réseaux internes ServiceNow ou avec d’autres schémas d’adresses IP internes de votre réseau, tout le trafic tunnelisé dans le domaine de chiffrement doit utiliser des adresses non RFC-1918 des deux côtés du tunnel.

ServiceNow fournit une adresse IP unique pour la source des requêtes sur votre réseau. Vous devez fournir des traductions d’adresses réseau (NAT) non RFC-1918 pour chaque hôte qui s’intègre à votre instance. Ces adresses publiques doivent appartenir à votre organisation. Les adresses tierces ne peuvent pas être utilisées à l’intérieur des tunnels. De plus, le domaine de chiffrement ne doit pas contenir l’adresse IP de l’homologue VPN.

Tunnels redondants

Il existe deux façons de créer une redondance pour vos tunnels :

• Vous utilisez le même domaine de chiffrement derrière vos deux pairs. Il s’agit de la méthode privilégiée.
• Utilisation d’un domaine de chiffrement différent derrière chaque homologue.

Avec la première méthode, vous devez fournir la même adresse NAT derrière chacun de vos pairs pour créer un chemin de connexion à l’aide de cette adresse à votre serveur. Le chemin vers votre serveur peut être la même machine physique ou un miroir qui fournit des services identiques. Avec cette méthode, votre instance utilisera la même adresse IP pour se connecter à vos serveurs, que votre tunnel primaire ou secondaire soit actif. Si vous avez plusieurs serveurs, suivez le même schéma pour vos serveurs supplémentaires. Cette méthode offre le plus de transparence à vos utilisateurs et est recommandée.

La deuxième méthode nécessite une configuration dans votre instance pour assurer la redondance. Lorsque le tunnel est utilisé pour LDAP, par exemple, vous pouvez fournir des serveurs LDAP redondants dans votre instance. Notez que cette méthode exige que la connexion au premier serveur LDAP configuré expire avant que l’instance ne tente de se connecter au serveur secondaire. En raison de ce délai supplémentaire, cette solution ne doit être mise en œuvre que si la première option est inaccessible. Notez également que tous les services ne peuvent pas être configurés de manière redondante dans votre instance. Si vous utilisez un tunnel VPN pour autre chose que LDAP et qu’une redondance est requise, vérifiez que votre configuration peut prendre en charge plusieurs adresses, ou consultez la première option ci-dessus.

Alternatives à l’utilisation d’un VPN

Ces alternatives simplifient la connexion de votre instance aux ressources des ServiceNow centres de données et offrent un meilleur chiffrement. En outre, vous pouvez éviter les problèmes que les temps d’arrêt du VPN pourraient causer, tels que rendre votre instance indisponible pour les utilisateurs en cas de problème avec le tunnel VPN.

Authentification unique (SSO) et MID Server

Envisagez d’utiliser une combinaison de Single Sign-On (SSO) pour l’authentification et du serveur MID pour la synchronisation des données utilisateur, plutôt que d’utiliser un VPN pour connecter votre serveur LDAP à votre instance. Pour les intégrations autres que LDAP, envisagez d’utiliser le chiffrement basé sur un certificat.

Vous pouvez utiliser l’écouteur LDAP sur un serveur MID pour synchroniser votre table d’utilisateurs en temps quasi réel.

L’avantage de cette approche est qu’il n’y a pas de trous de pare-feu, de routes, de tunnels VPN ou d’autres paramètres réseau spéciaux à configurer et à maintenir. La solution SSO/MID-Server est la méthode la plus flexible, la plus sécurisée et la plus rentable pour réaliser l’intégration LDAP complète.

LDAP sur SSL

Une autre alternative à l’utilisation d’un tunnel VPN consiste à configurer LDAP Over SSL (LDAPS) directement sur Internet. Vous pouvez configurer un contrôleur de domaine en lecture seule et verrouiller l’instance dans votre DMZ en utilisant uniquement les adresses source de l’instance et les ports de destination de votre choix. Étant donné que les ports LDAP sont configurables dans votre instance, vous pouvez effectuer une traduction d’adresse de port (PAT) si vous le souhaitez. Avec LDAPS, vous contrôlez le certificat qui est téléchargé via un canal chiffré vers l’instance, (voir Chargement d’un certificat sur une instance). Les paquets ne peuvent pas être chiffrés ou déchiffrés sans le certificat.

L’avantage de cette approche est qu’elle fournit un mécanisme de cryptage et de décryptage plus puissant. Un VPN ne peut crypter et déchiffrer le trafic entre les deux pairs assis sur Internet qu’avec une clé pré-partagée coordonnée, similaire à un mot de passe. LDAPS fournit un chemin chiffré plus long, de bout en bout, au niveau de la couche applicative et avec un certificat beaucoup plus compliqué qu’une clé prépartagée utilisée par le tunnel IPSec.

Configuration VPN

À partir du moment où une demande VPN est soumise, il faut généralement une semaine ou moins pour terminer la construction du VPN. Pour prendre en charge les exigences de redondance de votre instance et de votre organisation, un minimum de deux et un maximum de quatre VPN sont provisionnés (du site actif au vôtre ou du site actif à votre site de récupération d’urgence, et ainsi de suite).

Il est recommandé que le domaine de chiffrement soit aussi précis que possible. Idéalement, le domaine de chiffrement n’inclurait que les hôtes spécifiques requis pour les intégrations. Un grand domaine de cryptage peut créer des opportunités de divergences de routage (VPN contre Internet).

Pour créer le VPN, l’instance effectue les opérations suivantes :

1. Fournit les adresses de l’homologue VPN et de l’hôte de chaque centre de données.
2. Construit la connectivité VPN nécessaire à partir de deux centres de données dans votre réseau. Pour répondre aux exigences de redondance et de reprise après sinistre (DR), les VPN peuvent être provisionnés à partir de deux centres de données sur deux réseaux.

L’instance ne prend pas en charge la construction de plusieurs tunnels VPN dans un réseau client dans le but de se connecter à plusieurs régions géographiques ou filiales. Vous devez effectuer tout routage intersite, distribution ou mise en forme du trafic au sein de votre propre réseau interne, plutôt que d’avoir plusieurs tunnels VPN.