Skip To Content

Sécuriser la communication ArcGIS Server

Par défaut, ArcGIS Server applique l’utilisation du protocole HTTPS, créant un canal de communication sécurisé pour le trafic web. L’accès à des URL ArcGIS Server via HTTPS garantit la confidentialité et l’intégrité du réseau. Dans la mesure où les mots de passe envoyés par HTTP peuvent être interceptés et volés, les applications Esri qui peuvent se connecter à ArcGIS Server chiffrent le nom d’utilisateur et le mot de passe à l’aide de l’algorithme de cryptographie par clé publique RSA avant de transmettre les identifiants de connexion via le réseau.

L’utilisation du protocole HTTPS permet d’établir une protection contre les attaques d’intercepteur, au cours desquelles un agent malveillant intercepte les communications non sécurisées d’un réseau et se fait passer pour la source légitime des communications auprès du client et du serveur.

La communication via HTTPS est établie grâce à l’utilisation de certificats numériques. Les certificats sont signés par une autorité de certification afin de garantir la confiance entre le client et le serveur. ArcGIS Server dispose de sa propre autorité de certification et est fourni avec un certificat auto-signé par défaut, mais il est recommandé de configurer un certificat signé par une autorité de certification externe. En effet, la plupart des navigateurs émettent des avertissements ou vous découragent d’utiliser des certificats auto-signés, ce qui signifie que vous devez supprimer les avertissements si vous utilisez un tel certificat. Votre administrateur informatique devrait pouvoir vous fournir des certificats signés par une autorité de certification externe.

Reportez-vous à la rubrique À propos des certificats de serveur pour plus d’informations sur les certificats et obtenir les procédures détaillées des différentes configurations de certificat avec ArcGIS Server.

Modifier les paramètres de votre protocole HTTP

Il peut arriver, dans certains cas, que les administrateurs ArcGIS Server veuillent assouplir la restriction par défaut de la communication HTTP. La plupart du temps, cela permet d’autoriser la communication via HTTP et HTTPS. Pour ce faire, utilisez le répertoire administrateur ArcGIS Server.

  1. Connectez-vous au répertoire en tant qu’administrateur. L’URL est au format https://server.domain.com:6443/arcgis/admin.
  2. Accédez à Sécurité > Configuration > Mettre à jour.
  3. Ouvrez le menu déroulant Protocol (Protocole) et sélectionnez le protocole souhaité.
    Attention :

    Un administrateur définirait le protocole du site sur HTTP Only (HTTP uniquement) dans de très rares cas. Si vous n’en connaissez pas les raisons, définissez le protocole sur HTTP and HTTPS (HTTP et HTTPS) ou sur HTTPS Only (HTTPS uniquement).

  4. Cliquez sur Update (Mettre à jour) pour confirmer. Ceci redémarrera le serveur.

Activer le protocole HTTP Strict Transport Security

Si vous souhaitez appliquer une utilisation très stricte de HTTPS dans votre site ArcGIS Server, vous pouvez activer des en-têtes HTTP Strict Transport Security (HSTS). Une fois que ces derniers sont activés, le serveur envoie un en-tête Strict-Transport-Security avec toutes les réponses qu’il renvoie. Cet en-tête indique au navigateur du destinataire d’utiliser strictement des requêtes HTTPS vers le serveur pour une durée définie par l’en-tête (un an par défaut). HSTS est désactivé par défaut, mais renforce l’utilisation du protocole HTTPS Only (HTTPS uniquement).

Pour plus d’informations, reportez-vous à la rubrique Appliquer une communication HTTPS stricte.

Versions de TLS prises en charge

Transport Layer Security (TLS) est un protocole de chiffrement qui assure la sécurité des communications sur un réseau. ArcGIS Server prend en charge TLS version 1.2 par défaut. Vous pouvez également activer les versions 1.0 et 1.1 du protocole TLS. Pour plus d’informations, reportez-vous à la rubrique Restreindre les protocoles TLS et les suites de chiffrement.

Héritage :

Depuis la version 10.3, le protocole Secure Sockets Layer (SSL) n'est plus prise en charge en raison de la vulnérabilité POODLE de SSL 3.0.