Politiques de vérification des certificats de Serveur MID
Le serveur MID utilise quatre types de contrôles de sécurité pour sécuriser le trafic externe. Les contrôles de sécurité utilisent la validation des certificats TLS/SSL, la validation du nom d’hôte, la validation de la liste de révocation des certificats (CRL) et la validation OCSP (Online Certificate Status Protocol) pour améliorer la sécurité. Contrôlez ces contrôles de sécurité avec la table Politiques de vérification des certificats de Serveur MID.
Validation du certificat TLS/SSL
La sécurité du chiffrement TLS/SSL utilise le chiffrement asymétrique, également appelé chiffrement à clé publique. Ce chiffrement utilise deux clés cryptographiques : la clé publique et la clé privée. La clé publique est utilisée pour le chiffrement des données et est visible publiquement. La clé privée est utilisée pour le déchiffrement des données et sa sécurité est essentielle pour vérifier l’authenticité. Pour plus d’informations sur la préparation de votre réseau, consultez Serveur MID Politique de vérification des certificats TLS/SSL Informations sur la mise à niveau du Québec [KB0867397].
Lors de la validation d’un certificat TLS/SSL, le serveur MID tente de se connecter à un serveur Web sécurisé par un certificat TLS ou SSL. Le serveur Web envoie une copie de son certificat TLS/SSL au serveur MID. Le serveur MID vérifie l’authenticité du certificat et envoie un message au serveur Web. Le serveur Web répond par une acceptation signée numériquement pour l’initiation d’une session chiffrée TLS/SSL. Le serveur MID peut ensuite commencer à chiffrer la communication avec le serveur Web.
Validation du nom d’hôte
La vérification du nom d’hôte est une partie de HTTPS qui implique une vérification de l’identité du serveur pour s’assurer que le client parle au bon serveur. Cette vérification empêche l’envoi d’informations à un serveur après avoir été redirigé par une attaque de l’homme du milieu.
La vérification consiste à vérifier que le dnsName du certificat envoyé par le serveur correspond à l’URL utilisée pour effectuer la demande. Selon la RFC 6125, la vérification du nom d’hôte doit être effectuée par rapport au champ dNSName du certificat subjectAlternativeName. Dans certaines implémentations héritées, la vérification est effectuée par rapport au champ commonName du certificat. Si les noms ne correspondent pas, la connexion est interrompue.
Protocole OCSP (Online Certificate Status Protocol)
OCSP implique de contacter le serveur de l’autorité de certification distant et de vérifier le certificat avant que le serveur MID ne communique davantage avec le serveur cible. Les certificats compromis peuvent constituer une vulnérabilité de sécurité, surtout si ces certificats ont la capacité de signer d’autres certificats. Si les certificats ont été cassés ou falsifiés, une autorité de certification peut informer un client des certificats invalides et ne doivent pas être utilisés.
Un répondeur OCSP (un serveur généralement géré par l’émetteur du certificat) renvoie une réponse signée indiquant que le certificat est « bon », « révoqué » ou « inconnu ». S’il ne peut pas traiter la demande, il peut renvoyer un code d’erreur.
L’émetteur du certificat peut déléguer une autre autorité en tant que répondeur OCSP. Cela crée une chaîne de certificats qui doivent être vérifiés. Le certificat du répondant doit être délivré par l’émetteur du certificat en question. Le certificat de l’intervenant doit inclure une certaine extension qui le marque comme un pouvoir de signature OCSP.
Liste de révocation des certificats (CRL)
La vérification CRL offre une alternative à OCSP pour vérifier le statut de révocation du certificat. Plutôt que d’interroger un répondeur OCSP en direct, le serveur MID télécharge et met en cache les listes de révocation de certificats (CRL) à partir des URL fournies par l’autorité de certification (CA). Le serveur MID vérifie ensuite le statut de révocation des certificats par rapport à la liste de révocation de certificats mise en cache localement pendant l’établissement de liaison SSL/TLS. Si un certificat apparaît sur la liste de révocation de certificat, le serveur MID rejette la connexion et consigne l’événement.
Les listes de noms de certificats sont mises en cache localement et mises à jour périodiquement en fonction du calendrier de mise à jour de l’autorité de certification. Si le téléchargement d’une liste de réévaluation de certificats échoue, le système effectue de nouvelles tentatives conformément à une politique de nouvelle tentative configurable.
Politique de sécurité du serveur MID
Les politiques de sécurité du serveur MID contrôlent l’ensemble du trafic HTTPS provenant du serveur MID. Cela inclut les connexions HTTPS du serveur MID à un point de terminaison Internet, les URL ServiceNow, les points de terminaison intranet, ainsi que les points de terminaison cloud.
Ces connexions peuvent être classées en 4 politiques de sécurité :
- Politique de point de terminaison ServiceNow
- Cette politique est la valeur système par défaut exclusivement pour les URL ServiceNow. Sur la config.xml du serveur MID, il existe des propriétés d’amorce qui ne sont utilisées que pour établir une première connexion à l’instance et qui sont mises à jour avec la stratégie de system_default.
- Politique Internet
- Ces politiques couvrent toutes les connexions HTTPS initiées à partir d’un serveur MID vers n’importe quel point de terminaison sur Internet.
- Politique intranet
- Ces stratégies couvrent les sous-réseaux IP réservés, tels que les réseaux auto-hébergés.
- Politique de remplacement
- Vous pouvez remplacer des points de terminaison ou des URL spécifiques avec cette définition de politique. Les politiques remplacées occupent l’ordre de priorité le plus élevé pendant l’exploitation.
Les deux tables sont modifiables pour inclure ou exclure des plages IP et contrôlent le type de vérifications de validation de certificat à effectuer. Activez tous les contrôles de validation de certificat pour maximiser la sécurité. La version québécoise active toutes les politiques et vérifications par défaut pour les nouvelles installations.
Pour les points de terminaison qui hébergent un certificat auto-signé, importez le certificat dans le magasin de clés de confiance du serveur MID ou désactivez les contrôles de politique qui valident cet hôte. Pour plus d’informations sur l’ajout de certificats, reportez-vous à la section Ajouter des certificats SSL pour le serveur MID.
Après la mise à niveau vers Quebec, accédez à la table des politiques de vérification des certificats et apportez des modifications à la configuration des politiques si nécessaire. Une fois que le serveur MID démarre et se connecte à l’instance, toute connexion HTTPS ultérieure provenant du serveur MID commence à appliquer ces vérifications de certificat lors de l’exécution. Les connexions non sécurisées sont rompues avec des messages d’erreur appropriés.
Utiliser la politique de sécurité de l’instance
Le paramètre de configuration du serveur MID mid.ssl.use.instance.security.policy contrôle si le serveur MID utilise ses paramètres d’amorce plutôt que la politique de sécurité de l’instance. Par défaut, mid.ssl.use.instance.security.policy est définie sur false dans le config.xml afin que les politiques d’amorce ne soient pas remplacées par celles de l’instance.
Ce paramètre par défaut permet d’éviter certains problèmes lors de la configuration du serveur MID. Par exemple, si l’hôte ne parvient pas à joindre le répondeur OCSP, l’installation d’un nouveau serveur MID n’est pas perturbée par la politique d’une instance qui exige une connexion OCSP.
Le paramètre de configuration mid.ssl.use.instance.security.policy peut être défini pour chaque serveur MID. Lorsque la valeur est définie sur vrai, le serveur MID synchronise toutes les politiques avec l’instance et les paramètres de configuration d’amorce sont remplacés par la politique *.servicenow.com sur la table mid_cert_check_policy d’instance. Les politiques finales mettent à jour la carte de stratégie dans la mémoire du serveur MID ainsi que le config.xml.
<nom du paramètre="mid.ssl.bootstrap.default.check_cert_hostname » value="true"/><nom du paramètre="mid.ssl.bootstrap.default.check_cert_chain » value="true"/><nom du paramètre="mid.ssl.bootstrap.default.check_cert_revocation » value="false"/><nom du paramètre="mid.ssl.use.instance.security.policy » value="false"/>
Les instances auto-hébergées ou sur site doivent ajouter le paramètre suivant pour le config.xml : <nom du paramètre="mid.ssl.bootstrap.default.target_endpoint » value="FQDN_OF_THE_INSTANCE"/>