Toute communication envoyée sur un réseau d’ordinateurs peut être interceptée, déchiffrée ou modifiée. Pour sécuriser les communications réseau dans ArcGIS Enterprise, l’utilisation de HTTPS est recommandée et mise en œuvre par défaut.
Le protocole HTTPS chiffre les communications depuis et vers un serveur web. Cela permet de sécuriser les communications réseau en identifiant et en authentifiant le serveur web au niveau de chaque client web qui communique avec lui. L’utilisation du protocole HTTPS permet d’assurer la confidentialité et l’intégrité de toutes les données transmises.
Pour créer une connexion HTTPS entre un serveur web et un client, le serveur web a besoin d’un certificat de serveur. Un certificat est un fichier numérique contenant des informations sur l'identité du serveur Web. Ce certificat contient également la technique de chiffrement à utiliser lors de l'établissement d'un canal sécurisé entre le server Web et le client. Il doit être créé par le propriétaire du site Web et signé numériquement.
Esri recommande plusieurs pratiques par rapport aux certificats de serveur. Ces pratiques conseillées s’appliquent à tous les sites ArcGIS Server et au portail ArcGIS Enterprise, mais doivent également être envisagées pour d’autres composants de votre déploiement.
Remplacer les certificats auto-signés par des certificats signés par une autorité de certification
Après l’installation de ArcGIS Server et de Portal for ArcGIS, ces composants sont automatiquement configurés avec des certificats auto-signés. Ces certificats, qui ne sont signés que par le propriétaire d’un site Web, autorisent des communications HTTPS sans nécessiter d’étapes supplémentaires. Mais la plupart des navigateurs web n’auront pas tout de suite confiance dans les URL de votre déploiement ArcGIS Enterprise. De ce fait, vos utilisateurs ainsi que vous-même devrez supprimer les avertissements de navigateur, qui peuvent alarmer et susciter la suspicion.
Il vous est recommandé de configurer votre déploiement avec des certificats signés par une autorité de certification tierce dès que possible. Les certificats signés par une autorité de certification garantissent aux navigateurs web de vos utilisateurs que vos sites sont des sites fiables. Pour demander un certificat, faites une demande de connexion du certificat à l’autorité de certification.
Si vous disposez déjà d’un certificat signé par une autorité de certification, vous pouvez configurer ArcGIS Server avec ce certificat, puis importer celui-ci vers le portail.
Vous pouvez également demander à une autorité de certification de signer un certificat auto-signé, de configurer le nouveau certificat avec ArcGIS Server, puis de l’importer vers le portail.
Remarque :
S’assurer que les certificats racine et intermédiaires sont présents
Lorsqu’une application client vérifie votre certificat signé par une autorité de certification, elle doit également valider l’autorité de certification elle-même. Cela s’effectue à l’aide des certificats racine et intermédiaires, qui appartiennent à l’autorité de certification. Le certificat racine établit l’identité de l’autorité de certification, tandis que le certificat intermédiaire renforce sa crédibilité dans l’émission de certificats d’entité finale tels que les vôtres. Si les certificats racine et intermédiaires sont présents, les navigateurs et les applications client peuvent être assurés que votre certificat a bien été signé par une autorité de certification valide.
ArcGIS Enterprise se fie automatiquement aux certificats racine et intermédiaire signés par de nombreuses autorités de certification courantes. Si votre organisation utilise une autorité de certification personnalisée, ou si vous disposez d’un certificat intermédiaire spécifique que vous souhaitez ajouter à votre déploiement, vous pouvez utiliser les commandes importRootOrIntermediate figurant dans le répertoire administrateur de ArcGIS Portal Administrator et dans le répertoire administrateur de ArcGIS Server.
Inclure un autre nom d’objet dans vos certificats
Certains navigateurs, dont Google Chrome, ne se fient pas aux certificats ne possédant pas un autre nom d’objet (SAN, Subject Alternative Name), dont il peut en exister plusieurs. Si votre déploiement ArcGIS Enterprise est configuré avec des certificats ne possédant pas de valeur SAN, les utilisateurs de vos sites recevront des avertissement sur la fiabilité.
Les certificats créés par des administrateurs informatiques comportent généralement une ou plusieurs valeurs SAN, mais la commande makecert de Windows et l’application IIS Manager couramment utilisée ne permettent pas de configurer des valeurs SAN. Vous devez utiliser un autre outil pour générer vos certificats de domaine, qui sont signés par l’autorité de certification interne de votre organisation.
Si vous créez votre propre certificat de domaine sous Windows, Esri fournit un script permettant de créer un certificat de domaine contenant des valeurs SAN. Les certificats générés à l’aide de ce script PowerShell peuvent alors avoir la confiance de Chrome et autres navigateurs web.
Comprendre et résoudre le problème de non correspondance de nom
Parce que ArcGIS Enterprise peut être déployé sur plusieurs machines et potentiellement plusieurs domaines ou sous-domaines, il est important de connaître la cause et la solution potentielle du problème de non correspondance de nom. Ce problème se produit lorsqu’un utilisateur accède à une URL sur un site qui ne correspond pas au nom courant, ou plus récemment une valeur SAN, fourni par le certificat du site. En d’autres termes, si le certificat présenté par une page web est accordé pour une URL différente de celle à laquelle l’utilisateur accède, le navigateur signale une erreur.
Comme avec les certificats auto-signés, les utilisateurs peuvent choisir d’accepter l’URL et de s’y fier malgré l’erreur. Mais il s’agit d’une erreur alarmante pour les utilisateurs non familiarisés avec votre site, ainsi que d’un inconvénient fréquent.
La pratique conseillée consiste à ajouter immédiatement chaque domaine et sous-domaine nouveau que votre organisation utilise en tant que valeur SAN à votre certificat signé par une autorité de certification. Cette approche proactive évite aux utilisateurs de rencontrer des erreurs de non correspondance de nom.
Par exemple, imaginons une agence qui déploie des composants ArcGIS Enterprise sur deux sous-domaines, https://water.example.com et electricity.example.com. L’agence utilise un certificat signé par une autorité de certification, avec des valeurs SAN correspondant à « water.example.com » et « electricity.example.com. » Elle lance un nouveau site sur https://recycling.example.com. L’administrateur informatique doit ajouter une entrée « recycling.example.com » au paramètre SAN dans le certificat du site.
Rechercher des problèmes de sécurité à l’aide de scripts Esri
Pour vous aider à identifier les risques de sécurité courants dans votre déploiement ArcGIS Enterprise, Esri fournit des scripts qui vérifient les pratiques conseillées en matière de sécurité observées sur votre portail et vos sites de serveur. Les scripts serverscan.py et portalscan.py sont intégrés au logiciel et peuvent être exécutés à tout moment. Parmi les éléments examinés par les scripts figure une vérification établissant si le composant utilise ou non un certificat auto-signé.
Il est utile d’exécuter les analyses peu après l’installation de chaque composant, après la mise à niveau vers de nouvelles versions et après des modifications significatives apportées à votre déploiement ou à ses composants informatiques. Par exemple, vous devez ré-exécuter le script serverscan.py si votre organisation vient de remplacer ses certificats de serveur ou a changé les URL d’un site.
Vous avez un commentaire à formuler concernant cette rubrique ?