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.
Toutefois, il peut y avoir des exigences en matière de sécurité ou d’architecture réseau qui dictent l’utilisation d’une connexion de réseau privé virtuel (VPN) de sécurité du 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 cryptée nécessaire entre l’instance et votre réseau.
Connexions VPN
L’infrastructure ServiceNow VPN utilise des paires de périphériques 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 une pièce de 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é de trafic entrant dans votre réseau. Souvent, les intégrations qui utilisent le VPN ne disposent pas de chiffrement dans le cadre du protocole sous-jacent. Par exemple, LDAP sur VPN versus LDAPS sur Internet et HTTP sur VPN versus HTTPS sur Internet.
Le réseau n’autorise aucune intégration entrante vers ServiceNow ou tout trafic de l’utilisateur final vers ServiceNow de transiter par une connexion VPN. Cette communication restreinte inclut 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 autres que RFC-1918 des deux côtés du tunnel.
ServiceNow fournit une adresse IP unique pour la source des requêtes dans votre réseau. Vous devez fournir des adresses NAT (Network Address Translation) 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
- En utilisant le même domaine de chiffrement derrière vos deux pairs. C’est la méthode à privilégier.
- 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 homologues pour créer un chemin de connexion à l’aide de cette adresse vers votre serveur. Le chemin d’accès à 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 plus d’un serveur, 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 nécessite 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 offrent un moyen plus simple de connecter votre instance aux ressources des ServiceNow centres de données et offrent un meilleur chiffrement. De plus, vous pouvez éviter tous les problèmes que les temps d’arrêt VPN pourraient causer, tels que rendre votre instance indisponible pour les utilisateurs en cas de problème avec le tunnel VPN.
- Authentification unique et MID Server
Envisagez d’utiliser une combinaison de Single Sign-On (SSO) pour l’authentification et de 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 certificat.
Vous pouvez utiliser l’écouteur LDAP sur un MID Server pour synchroniser votre table utilisateur 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 sur 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 pour 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é sur un canal chiffré vers l’instance (reportez-vous à la section Chargement d’un certificat dans 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échiffrement plus puissant. Un VPN ne peut chiffrer 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 de VPN est soumise, il faut généralement une semaine ou moins pour terminer la version 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 vers votre site actif ou du site actif vers votre site DR, etc.).
Il est recommandé que le domaine de chiffrement soit aussi précis que possible. Idéalement, le domaine de chiffrement inclurait uniquement les hôtes spécifiques requis pour les intégrations. Un grand domaine de chiffrement peut créer des opportunités de divergences de routage (VPN par rapport à Internet).
- Fournit l’homologue VPN et les adresses d’hôte de chaque centre de données.
- Crée la connectivité VPN nécessaire à partir de deux centres de données dans votre réseau. Pour prendre en charge les exigences de redondance et de reprise après sinistre (DR), les VPN peuvent être provisionnés à partir de deux centres de données dans deux réseaux.
L’instance ne prend pas en charge la création 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 du trafic ou mise en forme du trafic au sein de votre propre réseau interne, plutôt que d’avoir plusieurs tunnels VPN.