Skip To Content

Pratiques conseillées en matière de sécurité

Lorsque vous sécurisez ArcGIS Server, il est essentiel que l’environnement dans lequel ArcGIS Server s’exécute soit également sécurisé. Vous pouvez appliquer plusieurs pratiques conseillées pour bénéficier d’une sécurité optimale.

Demander et configurer le certificat de votre propre serveur

ArcGIS Server est préconfiguré avec un certificat auto-signé, ce qui permet de tester initialement le serveur et de vérifier rapidement que votre installation a abouti. Cependant, dans la plupart des cas, une organisation doit faire une demande de certificat auprès d’une autorité de certification fiable et configurer le serveur pour qu’il l’utilise. Il peut s’agir d’un certificat de domaine émis par votre organisation ou d’un certificat signé par une autorité de certification.

Tout comme ArcGIS Server, le portail ArcGIS Enterprise inclut un certificat auto-signé préconfiguré. Si vous prévoyez de fédérer votre site avec un portail, faites une demande de certificat auprès d’une autorité de certification fiable et configurez le portail de sorte qu’il l’utilise.

La configuration d’un certificat émanant d’une autorité fiable est une pratique sûre pour les systèmes basés sur le Web, qui prévient l’émission d’avertissements du navigateur ou tout autre comportement inattendu. Si vous utilisez le certificat auto-signé inclus avec ArcGIS Server et le portail ArcGIS Enterprise lors du test, vous vous trouverez dans les cas de figure suivants :

  • Avertissements du navigateur Web, de ArcGIS Desktop ou de ArcGIS Pro concernant le manque de fiabilité du site. Lorsqu’un navigateur Web décèle un certificat auto-signé, il affiche généralement un avertissement et vous demande de confirmer votre souhait d’accéder au site. De nombreux navigateurs affichent des icônes d’avertissement ou une couleur rouge dans la barre d’adresse tant que vous utilisez le certificat auto-signé.
  • Impossibilité d’ouvrir un service fédéré dans Map Viewer ou Map Viewer Classic dans le portail, d’ajouter un élément de service sécurisé au portail, de se connecter à ArcGIS Server Manager sur un serveur fédéré, ou de se connecter au portail à partir de ArcGIS for Office.
  • Comportement inattendu en cas de configuration de services utilitaires, d'impression de services hébergés et d'accès au portail à partir d'applications clientes.
Attention :

La liste ci-dessus des problèmes que vous risquez de rencontrer avec un certificat auto-signé n'est pas exhaustive. Il est impératif d'utiliser un certificat signé par une autorité de certification pour tester et déployer entièrement votre portail.

Pour savoir comment configurer ArcGIS Enterprise avec un certificat signé par une autorité de certification, reportez-vous aux rubriques suivantes :

Recherchez les attaques de scripts de site à site

Les attaques de scripts de site à site (XSS) injectent et exécutent du code sur les pages Web existantes. L’attaquant amène souvent la victime, de manière trompeuse, à ouvrir cette page à l’aide de données ou d’une entrée qu’il fournit. Sur les sites ArcGIS Server, cette entrée ou ces données peuvent être des entités retournées par un service d’entités.

ArcGIS Server peut analyser les entités pour y rechercher des attaques XSS potentielles. Il peut analyser les entités lorsqu’elles sont ajoutées ou mises à jour via la fonctionnalité et également lorsqu’elles sont envoyées à des applications client. Toutefois, analyser du code malveillant dans une entité peut générer des faux positifs ou désactiver le code HTML légitime ayant été inclus dans des entités pour des fenêtres contextuelles HTML. Le comportement de l’analyse peut être configuré service par service.

Par défaut, lorsque des services sont créés, ils sont généralement configurés pour rechercher dans les mises à jour de possibles scripts et les bloquer, mais pas pour analyser les entités retirées du service d’entités. Un attaquant peut contourner cette analyse des mises à jour en modifiant les entités selon des méthodes qui ne nécessitent pas d’analyse, notamment en modifiant directement la base de données via SQL. Le plus sûr moyen de configurer vos services consiste à analyser toutes les entités. Analyser chaque entité extraite pour y rechercher des scripts peut réduire les performances, mais il s’agit d’une bonne pratique en matière de sécurité.

Changer les valeurs service par service pouvant être difficile à gérer, la méthode privilégiée consiste à définir une valeur par défaut à l’aide de la propriété featureServiceXSSFilter. Il s’agit d’une propriété système qui est utilisée pour créer des services. Elle est sans effet sur les services existants et peut être remplacée une fois qu’un service est créé.

Pour définir cette propriété système, connectez-vous au répertoire d’administrateur ArcGIS Server, puis cliquez sur System (Système) > Properties (Propriétés). Les propriétés sont représentées par un objet JSON. Copiez l’objet JSON existant et ajoutez-lui la propriété featureServiceXSSFilter.

La propriété featureServiceXSSFilter peut être définie sur input ou sur inputOutput. La valeur input, qui est la valeur par défaut, donne pour instruction à ArcGIS Server de configurer de nouveaux services d’entités afin d’analyser les mises à jour. La valeur inputOutput donne pour instruction à ArcGIS Server de configurer de nouveaux services d’entités afin d’analyser les mises à jour et les entités retournées.

Pour remplacer les paramètres d’un service spécifique, vous devez utiliser le répertoire d’administrateur de ArcGIS Server, rechercher le service en question, puis le modifier. Les trois propriétés utilisées sur la base d’un service d’entités particulier sont les suivantes :

  • xssPreventionEnabled permet de rechercher des scripts et du code dans les entités. Définissez cette propriété sur true.
  • xssPreventionRule peut être défini sur input ou inputOutput. Les modifications sont toujours analysées, mais les entités sortantes ne sont analysées que pour y rechercher les scripts si inputOutput est la valeur définie. Cela remplace la propriété système featureServiceXSSFilter.
  • xssInputRule détermine la réponse en cas de détection de code. Les options sont rejectInvalid ou sanitizeInvalid. La valeur rejectInvalid, qui est la valeur par défaut, est recommandée.

Restreindre les autorisations d'accès aux fichiers

Définissez les autorisations d’accès aux fichiers de telle sorte que seul l’accès nécessaire soit accordé au répertoire d’installation de ArcGIS Server, au magasin de configuration et aux répertoires du serveur. Le compte ArcGIS Server est le seul auquel le logiciel ArcGIS Server doit obligatoirement avoir accès. Il s’agit du compte utilisé pour l’exécution du logiciel. Votre organisation peut exiger que l’accès à d’autres comptes soit accordé. N’oubliez pas que le compte ArcGIS Server doit disposer d’un accès total au répertoire d’installation, au magasin de configuration et aux répertoires du serveur pour que votre site fonctionne correctement.

ArcGIS Server hérite des autorisations d’accès aux fichiers du dossier parent dans lequel il est installé. De plus, ArcGIS Server accorde l’autorisation d’accès au compte ArcGIS Server, de telle sorte qu’il puisse accéder au répertoire où il réside. Les fichiers créés en tant qu’exécutions ArcGIS Server (tels que des journaux) héritent des autorisations du dossier parent. Pour sécuriser le magasin de configuration et les répertoires du serveur, définissez des autorisations limitées sur le dossier parent.

Tout compte disposant d’un accès en écriture au magasin de configuration peut changer les paramètres de ArcGIS Server qui, normalement, ne peuvent être modifiés que par un administrateur du système. Si un magasin de sécurité intégré est utilisé pour gérer des utilisateurs, le magasin de configuration contient les mots de passe chiffrés qui leur sont associés. Dans ce cas, l'accès en lecture au Stockage de la configuration doit également être limité.

Si vous utilisez des services de carte ou de géotraitement sécurisés, verrouillez les autorisations de fichier sur les répertoires de serveur afin d’empêcher les comptes non autorisés d’avoir accès aux cartes et aux résultats des tâches de géotraitement.

Désactiver le compte d’administrateur de site principal

Le compte d’administrateur de site principal est celui que vous spécifiez au moment de la création d’un site dans ArcGIS Server Manager. Son nom et son mot de passe sont reconnus uniquement par ArcGIS Server. Il ne s’agit pas d’un compte de système d’exploitation et il est géré indépendamment des comptes utilisateur de votre magasin d’identités.

Désactivez le compte d’administrateur de site principal pour faire en sorte que le groupe ou le rôle que vous avez indiqué dans votre magasin d’identités constitue le seul et unique moyen d’administrer ArcGIS Server. Pour plus d'informations, reportez-vous à la rubrique Désactivation du compte d'administrateur de site principal.

Définir la clé partagée utilisée pour générer un jeton ArcGIS

Un jeton ArcGIS est une chaîne d'informations chiffrées. La clé partagée correspond à la clé cryptographique permettant de générer cette chaîne chiffrée. Plus la clé partagée sera complexe, plus il sera difficile pour un utilisateur malveillant de casser le code de chiffrement et de la déchiffrer. Si un utilisateur parvient à déchiffrer la clé partagée, à répliquer l'algorithme de chiffrement d'ArcGIS Server et à obtenir la liste des utilisateurs autorisés, il pourra générer des jetons et exploiter toutes les ressources sécurisées résidant sur cet ArcGIS Server.

Avant de définir une clé partagée, tenez compte des éléments ci-après :

  • La clé partagée doit comporter 16 caractères (les caractères spécifiés après les 16 premiers ne sont pas utilisés). Il est recommandé d'utiliser une suite de caractères aléatoires pour la clé. Tous les caractères peuvent être utilisés, y compris les caractères non alphanumériques.
  • La clé ne peut pas être un mot du dictionnaire, ni une valeur courante qui est facile à deviner. Dans la mesure où les utilisateurs ne doivent pas mémoriser la clé, ni l'utiliser, sa complexité ne constitue pas un problème (contrairement aux mots de passe).
  • Le jeton est chiffré avec la clé partagée à l'aide de la méthode de chiffrement AES (Advanced Encryption Standard), également connue sous le nom de Rijndael. Les 16 caractères de la clé correspondent aux 128 bits utilisés pour le chiffrement. Pour plus d'informations sur le chiffrement et AES, reportez-vous à des références sur la sécurité ou à quelqu'un dans votre organisation qui est compétent dans les domaines de la sécurité et du chiffrement.
  • Dans les environnements hautement sécurisés, il est conseillé de modifier régulièrement la clé partagée. N'oubliez pas que si vous modifiez la clé partagée, vous devrez peut-être mettre à jour vos applications pour qu'elles utilisent la nouvelle clé partagée. Tous les jetons intégrés existants deviendront invalides après la modification de la clé partagée.

Pour en savoir plus, reportez-vous à la rubrique A propos des jetons ArcGIS.

Utiliser un compte de service administré de groupe

Utilisez un gMSA (group Managed Service Account, compte de service administré de groupe) comme compte d’exécution de services ArcGIS Server. L’utilisation d’un gMSA permet d’allier les avantages d’un compte de domaine Active Director à la sécurisation du compte par des mises à jour périodiques des mots de passe.

En savoir plus sur les comptes de service administrés de groupe

Supprimez Python 2.x de votre système en désactivant la fonctionnalité ArcMap Runtime Support.

Python Software Foundation ne prend plus en charge le langage de programmation Python 2. Cela impacte ArcGIS Server, dans la mesure où les services basés sur ArcMap utilisent une installation de Python 2.x dans la configuration logicielle. Si le fait que Python 2.x soit installé sur votre système inquiète votre organisation, une option est désormais disponible pour le supprimer de votre déploiement ArcGIS Server.

Dans la version 10.9.1, la fonctionnalité ArcMap Runtime Support peut être désactivée des manières suivantes :

Si vous choisissez de désactiver la fonctionnalité ArcMap Runtime Support, l’environnement d’exécution de services ArcMap ne sera pas inclus avec ArcGIS Server, et Python 2.x ne sera pas installé. Vous devrez migrer ou republier les services ArcMap en vue d’utiliser l’environnement d’exécution de services ArcGIS Pro, qui utilise Python 3.x. Vous devez également recréer l’ensemble des extensions d’objet serveur (SOE) et des intercepteurs d’objet serveur (SOI) basés sur le SDK ArcObjects afin d’utiliser le SDK ArcGIS Enterprise après la migration ou la republication des services associés. Vous devrez aussi mettre à jour vos scripts et outils Python 2.x afin d’utiliser la syntaxe Python 3.x.

Remarque :

Si vous avez publié des services d’entités basés sur ArcMap et que les données ont été copiées sur une base de données gérée, la suppression du service n’entraînera pas la suppression des données copiées de la base de données gérée si la fonctionnalité ArcMap Runtime Support est désactivée.

ArcGIS Enterprise 10.9.1 est la dernière version à prendre en charge les services basés sur ArcMap. Après cette version, il ne sera plus possible de publier ni de consommer des services à partir de ArcMap (y compris ArcPy basé sur ArcMap) sur les sites ArcGIS Server. Les services qui font appel à l’environnement d’exécution de services ArcMap ne pourront plus s’exécuter s’ils sont présents au cours d’une mise à niveau vers une version suivante de ArcGIS Server. C’est pourquoi Esri recommande de migrer dès que possible vers les services ArcGIS Pro et Python 3.x.

Vous pouvez choisir de migrer vers les services ArcGIS Pro et Python 3.x dans la version antérieure à la version 10.9.1 que vous exécutez actuellement, de mettre à niveau vers la version 10.9.1 sans installer l’environnement d’exécution ArcMap, puis de valider la réussite de la migration. Vous pouvez également choisir d’installer la fonctionnalité ArcMap Runtime Support avec la version 10.9.1, puis la désactiver ultérieurement une fois vos services ArcGIS Pro et vos solutions personnalisées migrés. Vous pouvez réactiver la fonctionnalité ArcMap Runtime Support sur votre déploiement 10.9.1 si vous en ressentez le besoin au cours du processus de migration.

Transmettre des jetons ArcGIS de manière sécurisée

Pour éviter que les jetons ne soient interceptés et utilisés à mauvais escient, utilisez une connexion sécurisée par HTTPS. L’utilisation d’une connexion HTTPS permet de s’assurer que le nom d’utilisateur et le mot de passe envoyés par le client, ainsi que le jeton renvoyé par ArcGIS Server, ne sont pas interceptés. Pour plus d’informations, reportez-vous à la rubrique Sécuriser la communication de ArcGIS Server.

Lors de la création d’applications client ArcGIS personnalisées qui utilisent les demandes GET pour accéder aux services Web sécurisés via l’authentification par jeton ArcGIS, envoyez le jeton dans l’en-tête d’autorisation Esri X plutôt qu’un paramètre de requête. Cela évite aux intermédiaires du réseau, comme les proxys, les passerelles ou les équilibreurs de charge,d’être en mesure d’obtenir le jeton. L’exemple de demande HTTP GET ci-dessous envoie le jeton dans l’en-tête d’autorisation Esri X :

GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
    Host: arcgis.mydomain.com
    X-Esri-Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-

Si ArcGIS Server utilise l’authentification ArcGIS Server, et non l’authentification au niveau du Web (IWA, HTTP BASIC, PKI, etc.), l’en-tête d’autorisation HTTP standard peut être utilisé à la place de l’en-tête d’autorisation Esri X :

GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
    Host: arcgis.mydomain.com
    Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-

Utiliser des requêtes standardisées

ArcGIS Server propose une option de sécurité, appelée requêtes standardisées, qui garantit une protection accrue contre les attaques par injection de code SQL. Cette option est activée par défaut.

Si vous êtes un administrateur de serveur, nous vous conseillons de garder cette option de sécurité activée et de demander aux développeurs de l'application de créer des instructions de clause WHERE qui utilisent une syntaxe indépendante de la base de données. En désactivant cette option , vous risquez d’exposer davantage votre système aux attaques par injection de code SQL.

Pour en savoir plus, reportez-vous à la rubrique A propos des requêtes standardisées.

Désactiver le répertoire des services

Vous pouvez désactiver le répertoire des services pour limiter le risque que vos services soient explorés, repérés dans une recherche Web ou interrogés via des formulaires HTML. En désactivant le répertoire des services, vous renforcez également la protection contre les attaques par exécution XSS.

La décision de désactiver le répertoire des services dépend de la fonction de votre site et de son degré de fréquentation par les utilisateurs et les développeurs. Si vous désactivez le répertoire des services, vous devrez peut-être préparer d’autres listes ou métadonnées sur les services disponibles sur votre site.

Pour savoir comment désactiver le répertoire des services, reportez-vous à la rubrique Désactivation du répertoire des services.

Restriction des requêtes inter-domaines

Les requêtes inter-domaines sont utilisées dans de nombreuses attaques menaçant les systèmes. Il est recommandé de réserver l’utilisation des services ArcGIS Server à des applications hébergées uniquement par des domaines de confiance. Pour en savoir plus, reportez-vous à la rubrique Limitation des requêtes de plusieurs domaines destinées à ArcGIS Server.