Lorsqu’une application, une carte ou un service Web est mis à disposition par le biais d’un site Web public ou d’une application publique (accessible sur Internet et de manière anonyme), généralement à l’intention d’utilisateurs publics, une question courante est de savoir comment cet accès peut être correctement sécurisé. Les organisations souhaitent faciliter l’accès aux utilisateurs, tels que le grand public, en n’exigeant pas d’authentification ou de compte spécifique. Naturellement, ils veulent s’assurer que les données ne sont pas utilisées à mauvais escient, consultées ou conservées de manière inappropriée par ces utilisateurs finaux.
Dans la plupart des processus Web, un client (souvent un navigateur Web) demande des informations à un serveur Web, généralement sous la forme d’une image de carte, d’un ensemble d’entités et d’attributs spatiaux ou d’une tuile de carte raster ou vectorielle. Ces requêtes aboutissent à une réponse qui est renvoyée au client. Celui-ci transfère cette représentation partielle ou complète des données vers l’appareil client de l’utilisateur, où elle est utilisée pour afficher un indicateur ou une image ou fournir l’expérience cartographique souhaitée. Les considérations relatives à l’accès aux données ainsi que les types de services courants sont indiqués.
Lors de l’accès aux couches d’images de carte, également appelées services de carte dynamiques, l’image de réponse ne contient que des pixels. Il s’agit de la représentation des données avec une configuration cartographique spécifique. Elle est générée sur un serveur et renvoyée au client sous forme d’image. Les services de carte peuvent être configurés pour n’autoriser que ce type d’image de carte dynamique. Pour ce faire, il suffit de désactiver la fonctionnalité Requête du service de carte. Cela empêchera le partage des enregistrements de données individuels avec le client. Cette configuration peut toutefois réduire les fonctionnalités et ne doit être envisagée que lorsqu’un simple affichage de la carte est suffisant.
Les couches d’entités peuvent être créées à partir de services de carte ou d’entités. Elles diffèrent des couches d’images de carte, car elles nécessitent que les données de l’entité, y compris sa géométrie et ses attributs, soient renvoyées du serveur au client et soient affichées dans le navigateur client. Toute couche d’entités accessible au public envoie, en permanence, des blocs de données au client. Il peut s’agir d’une demande portant sur une certaine étendue géographique ou d’un ensemble d’entités envoyées simultanément à partir du serveur. Lorsqu’une application utilise une couche d’entités, les données sont téléchargées par le client afin de les afficher correctement. Étant donné que les couches d’entités reposent sur ce transfert de données vers le client, des exigences telles que « Je veux m’assurer que les utilisateurs ne téléchargent pas de données » sont incompatibles, sur le plan fonctionnel, avec une application ou un processus qui dépend des couches d’entités.
Les services d’imagerie permettent aux utilisateurs de demander dynamiquement une étendue spécifique pour générer une image. La résolution d’image d’origine peut renvoyer une représentation raster réelle des données jusqu’à la taille maximale d’image autorisée par le service. Ces images sont également téléchargées sur le client, tel qu’un client Web, un client bureautique ou un client mobile, et partagent ce sous-ensemble de données directement avec le client. Les services d’imagerie prennent également en charge une fonctionnalité de téléchargement (non activée par défaut), ce qui permet de télécharger l’image d’origine ou un format converti. Cette fonctionnalité doit généralement être désactivée, sauf si elle est spécifiquement requise par une application.
Dans les types de services ci-dessus, le scénario de la couche d’images de carte est le seul qui permette de restreindre véritablement les données en fonction de l’accès utilisateur. Comme le moyen de transmission des données se fait par le biais d’une image rendue, aucun attribut ni aucune géométrie spécifique n’est disponible.
Lorsque les données et les services sont rendus publics, plusieurs méthodes permettent d’appliquer un certain niveau de restriction au service, afin de réduire le nombre d’utilisateurs ou l’exposition au public.
La limitation basée sur le référent est un modèle courant de restriction de l’utilisation des données. Cela nécessite un proxy inverse ou un autre type de proxy capable d’inspecter les requêtes HTTP individuelles adressées au service, et de rejeter celles qui ne fournissent pas l’en-tête de requête HTTP du référent avec une valeur correspondant à une liste d’autorisation. Par convention, tous les navigateurs génèrent et envoient cet en-tête de requête à partir d’applications qui demandent des ressources à partir d’un autre domaine. Il s’agit donc d’une méthode fiable pour contrôler le trafic basé sur le navigateur.
Cela peut être une parade efficace contre une utilisation abusive, sans pour autant sécuriser complètement les données. Un en-tête de référent peut facilement être usurpé par un tiers motivé ou ajouté à une requête scriptée ou programmatique pour permettre à la requête de passer par le proxy. La portée des clés API d’ArcGIS Location Platform peut être configurée de façon à prendre en charge uniquement des domaines spécifiques dans l’en-tête de référent. Il est possible également de lui appliquer une restriction pour éviter qu’elle soit utilisée par une application sur ce domaine ou par un tiers motivé capable d’usurper cette valeur d’en-tête.
La restriction des requêtes en fonction d’une plage d’adresses IP source est un autre moyen de sécuriser l’accès. Elle peut permettre de demander une ressource de manière anonyme, mais uniquement lorsque l’adresse IP d’origine de la requête se trouve dans une plage attendue, comme un réseau local ou une adresse IP externe basée sur la traduction d’adresses réseau (NAT) pour une organisation. Ces restrictions peuvent être appliquées au niveau d’un serveur Web, d’un équilibreur de charge ou d’un proxy inverse. Les filtres basés sur IP peuvent également être utiles pour filtrer l’accès à partir de certains pays ou de certaines zones géographiques, ou pour autoriser l’accès à partir d’un système particulier avec une adresse IP externe fixe.
L’utilisation d’une clé API est une autre méthode courante pour restreindre la réutilisation d’une couche publique. Il est nécessaire pour cela d’ajouter une clé API à chaque requête, laquelle sera validée par une couche de gestion des API ou de proxy inverse. Les requêtes qui n’incluent pas de clé API valide seront rejetées. Même si cela est efficace pour prévenir une simple utilisation abusive, il est relativement facile pour un utilisateur motivé d’identifier la clé API utilisée et de la réutiliser pour effectuer des requêtes dans sa propre application ou service. Les clés API sont envoyées depuis le navigateur ou l’application cliente vers le serveur, de sorte qu’elles sont toujours visibles par le client et peuvent être potentiellement extraites et réutilisées à d’autres fins. La meilleure méthode pour atténuer ce risque consiste à appliquer des référents autorisés par clé et à surveiller les clés pour détecter toute utilisation inattendue ou malveillante.
En résumé, lorsque le public visé par une application ou un service est le grand public, il est préférable de considérer toutes les données accessibles dans cette application comme étant entièrement publiques. La plupart des restrictions suggérées ci-dessus peuvent être contournées. Un tiers motivé sera capable de trouver un moyen d’extraire une copie des données pour les réutiliser. La gestion minutieuse de l’accès, des avis de non-responsabilité et la mise à disposition des données via des sites de données publics sont autant de méthodes pour atténuer le risque lié au partage public des données. Grâce à ces pratiques, certaines préoccupations concernant l’utilisation inappropriée peuvent être partiellement minimisées.