--- sourceDocument: Options de la plateforme d’IA ServiceNow de Yokohama sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/yokohama/servicenow-platform Release : - yokohama ft:locale : - fr-FR ft:publication_title : - Options de la plateforme d’IA ServiceNow de Yokohama ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Magasin de clés unifié du serveur MID # Magasin de clés unifié du serveur MID {#ariaid-title1} * Rversion finale: Yokohama * * Mis à jour 30 janv. 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 minutes de lecture Le magasin de clés unifié du serveur MID permet à tous les produits sur le serveur MID d'utiliser des certificats et des paires de clés communs. Cette fonctionnalité permet aux applications d'utiliser le même canal de communication sécurisée vers le serveur MID que celui utilisé par le serveur MID pour se connecter à l'instance. |-| | | [ ] {#mid-unified-keystore__table_m2t_cv4_nhb} Au démarrage du serveur MID, le nom courant (CN) du certificat est inspecté pour identifier si un certificat personnalisé a été installé. Si un certificat personnalisé est détecté, la création du certificat/de la paire de clés est ignorée et un attribut est défini sur l'enregistrement ecc_agent pour indiquer l'utilisation d'un certificat personnalisé. Lorsqu'un certificat personnalisé est utilisé, l'action d'interface utilisateur de renouvellement de saisie est désactivée sur l'instance pour le serveur MID. Une nouvelle action d'interface utilisateur appelée Supprimer la paire de clés personnalisée est disponible pour revenir à l'utilisation d'un certificat auto-signé. L'utilisation de cette action entraîne la suppression du certificat personnalisé par le serveur MID et la génération d'un nouveau certificat auto-signé, similaire à l'option de renouvellement de saisie. Lorsqu'un serveur MID est mis à niveau, tous les certificats personnalisés qui ont été installés sont conservés. ## Prise en charge des bundles PEM {#mid-unified-keystore__section_xyn_43q_wnb} Le magasin de clés unifié du serveur MID prend en charge les paires de clés et de certificats groupés PEM. ## Exemple d'ensemble PEM {#mid-unified-keystore__section_c3c_q3q_wnb} -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0pj5O8QKFpHy9 ... oPdU+h0grs9SJp6rFx0PzDY= -----END PRIVATE KEY----- Bag Attributes friendlyName: localKeyID: 54 69 6D 65 20 31 35 39 35 33 35 34 32 30 38 30 35 31 subject=/C=US/ST=CA/L=Santa Clara/CN=epic1016883 issuer=/C=US/ST=CA/L=Santa Clara/CN=epic1016883 -----BEGIN CERTIFICATE----- MIIDKzCCAhOgAwIBAgIEPqMQqDANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJV ... 4g53RN+LqtJVeeQkZvIbZOfuSqypdVfudkS8dqxQALb8IuHUV7JOcBvOT79mSTs= -----END CERTIFICATE----- **Concepts associés** * [Politiques de vérification des certificats de Serveur MID](https://servicenow-prod.fluidtopics.net/Pl2yW7uO43uXy7Gi8PHCzA "Le serveur MID utilise trois 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 et la validation OCSP 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.") * [Informations d'identification d'authentification du serveur MID et demandes SOAP](https://servicenow-prod.fluidtopics.net/dIXun15wZVfGj0sWkOStpw#mid-authentication-soap-requests "Définissez les informations d’identification d’authentification de base pour mettre à jour les données d’invocation du service web. Pour plus de sécurité, vous pouvez appliquer l’authentification de base à chaque demande SOAP entrante vers le serveur MID.") * [Serveur MID Journal d'audit de commande](https://servicenow-prod.fluidtopics.net/aGBuY8P3tJIpG01C0OnEHg "Le journal d’audit des commandes enregistre les commandes exécutées par pour Serveur MID l’application Découverte . Examinez les commandes pour vérifier s’il y a des anomalies ou des erreurs.") * [Mode FIPS appliqué du serveur MID](https://servicenow-prod.fluidtopics.net/xly0FzzUTaeJEPzVgN6D7g#mid-fips-enforced "Le serveur MID prend en charge l’environnement NSC (National Security Cloud) IL-5, qui exige que toutes les cryptoographies utilisées soient validées par FIPS. Le serveur MID peut être exécuté en mode FIPS appliqué, où seuls les algorithmes de chiffrement validés par FIPS sont utilisés.") * [Gouvernance de serveur MID](https://servicenow-prod.fluidtopics.net/ke9Asb~0l6JC_bOAPlkcKw "Améliorez Serveur MID la sécurité en définissant un délai d’expiration automatique pour invalider et arrêter inactif Serveurs MID. Vous pouvez activer cette fonctionnalité et définir le délai d’expiration d’inactivité globalement et pour chaque Serveur MID.") **Tâches associées** * [Chiffrer ou déchiffrer les valeurs des fichiers de configuration de serveur MID](https://servicenow-prod.fluidtopics.net/Q1u2WTPTqkAJV8UTwSLqvw "La valeur de n’importe quel paramètre du serveur MID dans le fichier config.xml peut être chiffrée. Les attributs de toutes les valeurs chiffrées sont gérés à partir du fichier de configuration, y compris l’attribut de sécurité du mot de passe de connexion.") * [Activer l'authentification réciproque du serveur MID](https://servicenow-prod.fluidtopics.net/03OdSt4nj4brVrQM6a5zEQ "Configurez le serveur MID de sorte qu’il utilise un certificat client pour s’authentifier auprès de l’instance. Cela évite d’avoir à créer des informations d’identification d’authentification de base dans le magasin de clés pour la configuration du serveur MID.") * [Serveur MID : intégration de Azure Key Vault](https://servicenow-prod.fluidtopics.net/1erp7~RUWTszwcPJMyoE7A#mid_azure_key_vault_integration "L’intégration du serveur MID au coffre-fort de clés Azure permet à Orchestration, Découverte et Mappage des services de s’exécuter sans stocker d’informations d’identification sur l’instance.") * [Retapez la clé d'un serveur MID](https://servicenow-prod.fluidtopics.net/U2m_FmrgVh5jAO1nrY8Ypg "Retapez la clé d’un serveur MID pour générer une nouvelle clé privée. Les clés privées sont utilisées pour déchiffrer les informations d’identification permettant aux serveurs MID de transmettre des informations en toute sécurité. Les paires de clés sont initialement générées lorsqu’un serveur MID est validé, et la saisie des serveurs MID doit être renouvelée périodiquement pour répondre aux exigences de sécurité.") * [Ajouter des certificats SSL pour le serveur MID](https://servicenow-prod.fluidtopics.net/KnDhe_BkYE2nyTJsjGY~5g#add-ssl-certificates "Configurez le serveur MID pour vous connecter à une source via SSL.") * [Joindre un fichier de script à un fichier synchronisé Serveur MID](https://servicenow-prod.fluidtopics.net/CsmvsPWrNFSP7LUAM3uTvg#mid-server-script-attach "Vous pouvez joindre un fichier de script à synchroniser avec un serveur MID connecté. Windows La sécurité renforcée d’Internet Explorer bloque les fichiers téléchargés qu’elle juge potentiellement dangereux. Cependant, la synchronisation des fichiers permet d’éviter ce problème de sécurité.") **Référence associée** * [Sécurité du fichier de configuration de serveur MID](https://servicenow-prod.fluidtopics.net/5JlufBa7tOlcfvwvToefSQ "Les données sensibles de configuration de serveur MID peuvent être protégées à l’aide de plusieurs schémas différents, notamment le chiffrement des données internes et externes et le stockage des données externes.") * [Algorithmes de chiffrement SSH de serveur MID](https://servicenow-prod.fluidtopics.net/2DWkoEtbbHIaQrOnLsLZ1A "Le serveur MID utilise des clients SSH pour effectuer de nombreuses actions de découverte. Au cours de l’établissement de liaison SSH, le client et le serveur déterminent d’abord les algorithmes pris en charge par les deux parties, puis le client choisit l’algorithme de priorité la plus élevée. Pour l’algorithme de clé d’hôte, le client choisit l’algorithme de priorité la plus élevée pris en charge par les deux parties qui correspond au type de clé.") ## Installer des certificats personnalisés dans le magasin de clés unifié du serveur MID {#ariaid-title2} Installez des certificats personnalisés pour unifier les canaux de sécurité pour diverses applications. ### Avant de commencer Rôle requis : admin Lors de l'installation du certificat sur un serveur MID hébergé sous Linux, `install-certificate.sh` peut ne pas répondre si le nombre de pools d'entropie Linux est inférieur à quelques centaines. Vérifiez le nombre d'entropies du générateur de nombres pseudo-aléatoires Linux (PRNG) avec la commande suivante : cat /proc/sys/kernel/random/entropy_avail Si le nombre d'entropies est trop faible, vous pouvez installer un générateur d'entropie tel que RNGD ou Haveged. Pour plus d'informations sur l'installation de Haveged pour CentOS et Ubuntu, consultez [Comment configurer une entropie supplémentaire pour les serveurs cloud à l'aide de Haveged](https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged). ### Procédure 1. Si le serveur MID est en cours d'exécution, arrêtez-le. Remarque : Si l'entrée de l'alias DefaultSecurityKeyPairHandle est modifiée, vous devez invalider le serveur MID avant de l'arrêter. 2. Créez un certificat de lot PEM et une paire de clés en exécutant l'une des commandes suivantes dans le dossier d'installation de Serveur MID. * Générez des certificats auto-signés pour les cas d'utilisation non MTLS avec la commande : openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem * Exportez le magasin de clés vers un ensemble PEM à l'aide de la commande : openssl pkcs12 -in .p12 -nodes -out .pem * Obtenez uniquement des certificats au format PEM avec la commande : openssl pkcs12 -in .p12 -out .pem -clcerts -nokeys * Obtenez uniquement les clés au format PKCS#8 avec la commande : openssl pkcs12 -in .p12 -out .key -nocerts -nodes * Installez le certificat, ou la chaîne de certificats et la clé privée pour les hôtes Windows à l'aide de la commande : bin/scripts/manage-certificates.bat -a * Installez le certificat, ou la chaîne de certificats et la clé privée pour les hôtes Linux à l'aide de la commande : bin/scripts/manage-certificates.sh -a {#mid-unified-keystore-install__ul_m5t_pjg_xnb} Remarque : L'en-tête et le pied de page de la syntaxe PEM doivent être les suivants : -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- L'en-tête et le pied de page de la syntaxe PKCS#8 doivent être les suivants : -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- 3. Démarrez le serveur MID. 4. Validez le serveur MID avec l'instance. 5. **Facultatif :** Pour rétablir le serveur MID afin qu'il utilise un certificat auto-généré, sélectionnez le serveur MID dans l'instance et utilisez l'action d'interface utilisateur Supprimer le certificat personnalisé. Remarque : Il est également possible de rétablir le serveur MID à l'aide de l'action d'interface utilisateur Invalider le serveur MID. L'invalidation d'un serveur MID supprime tous les certificats personnalisés installés et crée un nouveau certificat auto-signé pour le serveur MID. ### Que faire ensuite Le manage-certificates possède les fonctions suivantes et les scripts doivent être exécutés à partir du dossier de l'agent. Activer l'authentification réciproque : Sous Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -m` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -m` Supprimer l'authentification réciproque et restaurer l'authentification de base : Sous Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -b ` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -b ` Ajouter de nouveaux certificats et chaînes de certificats avec un alias spécifié : Pour Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -a ` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -a ` `L'alias` est un nom unique attribué au certificat en cours d'importation. Le serveur MID demande un certificat personnalisé pour l'authentification réciproque, avec le nom d'alias par défaut `defaultSecurityKeyPairhandle`. Pour configurer la communication MTLS entre le serveur MID et l'instance, l'entrée de certificat doit être ajoutée au magasin de clés à l'aide du nom d'alias `defaultSecurityKeyPairhandle`. Le `fileName` est un chemin de fichier qui peut contenir un certificat PEM, ou une chaîne de certificats, et une clé privée PCKS#8. Le chemin d'accès au groupe PEM peut contenir plusieurs certificats et une seule clé privée. L'en-tête et le pied de page de chaque certificat PEM doivent être les suivants : -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- L'en-tête et le pied de page de la syntaxe PKCS#8 doivent être les suivants : -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- Une exception est levée si la chaîne de certificats échoue à la validation. Si le fichier contient plusieurs certificats, ils doivent être ordonnés : certificat terminal, certificats intermédiaires, puis certificats racines. Afficher les détails du certificat pour l'alias spécifié : Sous Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -g ` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -g ` Cette commande affiche des informations telles que le nom unique de l'objet, le nom de l'émetteur et la date d'expiration du certificat. Répertorier tous les alias existants : Pour Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -l` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -l` Cette commande répertorie tous les noms d'alias disponibles dans le agent_keystorefichier . Supprimer les certificats à l'aide d'un alias : Sous Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -d ` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -d ` Cette commande supprime l'alias et l'enregistrement du magasin de clés. L'entrée de l'alias peut être supprimée à l'aide de DefaultSecurityKeyPairHandle cette commande. Supprimer toutes les entrées du magasin de clés : Sous Windows, utilisez la commande : `bin/scripts/manage-certificates.bat -r ` Pour Linux, utilisez la commande : `./bin/scripts/manage-certificates.sh -r ` Cette commande supprime les entrées existantes du magasin de clés, à l'exception de l'alias DefaultSecurityKeyPairHandle. **Tâches associées** * [Activer l'authentification réciproque du serveur MID](https://servicenow-prod.fluidtopics.net/03OdSt4nj4brVrQM6a5zEQ "Configurez le serveur MID de sorte qu’il utilise un certificat client pour s’authentifier auprès de l’instance. Cela évite d’avoir à créer des informations d’identification d’authentification de base dans le magasin de clés pour la configuration du serveur MID.") ## Restaurer le magasin de clés du serveur MID avec une copie de sauvegarde {#ariaid-title3} Si le magasin de clés est corrompu ou supprimé accidentellement, vous pouvez restaurer une copie de sauvegarde du magasin de clés du serveur MID. Cela est particulièrement utile pour les magasins de clés avec des paires de clés personnalisées, car la recréation de données de paires de clés personnalisées peut être difficile et prendre du temps. ### Avant de commencer Rôle requis : administrateur d'agent ### Pourquoi et quand exécuter cette tâche À partir de la version Tokyo, le serveur MID effectue automatiquement une sauvegarde du fichier agent_keystore lorsqu'il est modifié. Les sauvegardes sont stockées dans security_backup sous le dossier de l'agent. Ils sont stockés en dehors du dossier de sécurité pour se protéger contre les suppressions accidentelles ou les corruptions du dossier de sécurité. Dans le dossier de sauvegarde, il y a un fichier journal de sauvegarde dédié : keystore_backup_audit_trail.log. Ce journal assure le suivi des fichiers de sauvegarde et des activités de sauvegarde. Chaque entrée de journal de sauvegarde a un nom de fichier de sauvegarde avec un horodatage, un keypairs.mid_id correspondant et une liste d'alias de paires de clés dans la sauvegarde. Remarque : Pour des raisons de sécurité, le magasin de clés de sauvegarde doit avoir les mêmes attributs que le magasin de clés d'origine, tels que le propriétaire, le groupe et les autorisations. Ces attributs garantissent au serveur MID la même protection au niveau du système de fichiers. Les sauvegardes du magasin de clés peuvent être modifiées à l'aide des propriétés du serveur MID mid.keystore.max_backups, mid.keystore.max_live_backups et mid.keystore.backup_overwrite_timespan. Consultez [Propriétés du serveur MID](https://servicenow-prod.fluidtopics.net/2LgAvSx8mPAogV9hkI~RZA#r_MIDServerProperties "Les propriétés contrôlent le comportement de tous les serveurs MID ou d’un serveur MID particulier.") pour plus d'informations. ### Procédure 1. Arrêtez le serveur MID. 2. Accédez au security_backup et affichez les keystore_backup_audit_trail.log pour choisir la sauvegarde à restaurer. 3. Copiez cette sauvegarde dans le fichier agent_keystore dans le dossier de sécurité. Vérifiez les autorisations du fichier pour vous assurer qu'il a le même propriétaire et les mêmes autorisations que celui d'origine. Si agent_keystore existe déjà à cet emplacement, remplacez-le avec la copie de sauvegarde. 4. Vérifiez config.xml pour vous assurer que le keypairs.mid_id correspond à celui du fichier journal d'audit. 5. **Facultatif :** Si les keypairs.mid_id ne correspondent pas, mettez à jour les config.xml pour qu'ils correspondent. 6. Accédez à l'instance et invalidez le serveur MID. Cela créera une commande système delete_mid_keypair dans le ecc_queue. 7. Recherchez tous les messages de sortie delete_mid_keypair pour le serveur MID et marquez-les comme traités. L'objectif est de marquer le serveur MID comme invalidé sans déclencher la suppression de la paire de clés. À moins que les commandes système ne soient marquées comme traitées, le serveur MID supprime la paire de clés defaultsecuritykeypairhandle , qu'elle soit personnalisée ou générée automatiquement. 8. Redémarrez le serveur MID. 9. Accédez à l'instance et validez le serveur MID.