A la hora de ofrecer un servicio de aplicaciones, mapas o web a través de un sitio web o aplicación públicos (orientados a Internet y accesibles de forma anónima), normalmente para usuarios públicos, una pregunta habitual es cómo se puede proteger adecuadamente este acceso. Las organizaciones desean facilitar el acceso a los usuarios, como el público en general, al no requerir autenticación ni una cuenta establecida. Es comprensible que quieran estar seguros de que estos usuarios finales no hacen un mal uso de los datos, no acceden a ellos de forma indebida ni se los quedan.
En la mayoría de los flujos de trabajo basados en la web, un cliente (a menudo un navegador web) solicita información a un servidor web, generalmente en forma de una imagen de mapa, un conjunto de características y atributos espaciales o una tesela de mapa ráster o vectorial. Estas solicitudes dan lugar a una respuesta que se devuelve al cliente, que traslada esta representación parcial o total de los datos al dispositivo cliente del usuario, donde se utiliza para representar un indicador o una imagen o proporcionar la experiencia cartográfica deseada. Los tipos de servicios comunes conllevan consideraciones relativas al acceso a los datos.
Cuando se accede a capas de imágenes de mapa, también conocidas como servicios de mapas dinámicos, la imagen de respuesta contiene solo píxeles, que es una representación de los datos con una configuración cartográfica específica. Se genera en un servidor y se devuelve al cliente en forma de una imagen. Los servicios de mapas pueden configurarse para que solo permitan este tipo de imágenes de mapas dinámicos. La forma de hacerlo es deshabilitando la funcionalidad de consulta del servicio de mapas. Con ello, se evita que cualquier registro de datos individual sea compartido con el cliente. Sin embargo, esta configuración puede reducir la funcionalidad y solo debe tenerse en cuenta cuando la simple visualización del mapa es suficiente.
Las capas de entidades pueden crearse a partir de servicios de mapas o entidades. Se diferencian de las capas de imágenes de mapa en que requieren que los datos de las entidades, incluidos su geometría y sus atributos, se devuelvan del servidor al cliente y se representen en el navegador del cliente. Cualquier capa de entidades de acceso público está enviando continuamente trozos de datos al cliente, que puede ser una solicitud de una determinada extensión geográfica o un conjunto de características del servidor a la vez. Cuando una aplicación hace uso de una capa de entidades, el cliente descarga los datos para poder representarlos correctamente. Dado que las capas de entidades dependen de esta transferencia de datos al cliente, requisitos como «quiero asegurarme de que los usuarios no descargan datos» son funcionalmente incompatibles con una aplicación o flujo de trabajo que dependa de las capas de entidades.
Los servicios de imágenes permiten a los usuarios solicitar dinámicamente una extensión específica para generar una imagen. La resolución de la imagen original puede devolver una representación ráster real de los datos hasta el tamaño máximo de imagen que permita el servicio. Estas imágenes también se descargan en el cliente, como un cliente web, de escritorio o móvil, y de hecho están compartiendo ese subconjunto de datos directamente con el cliente. Los servicios de imágenes también admiten una funcionalidad de descarga, que no está habilitada de forma predeterminada, que puede permitir la descarga de la imagen original o de un formato convertido. Por lo general, esta funcionalidad debe deshabilitarse a menos que se requiera específicamente para la funcionalidad en una aplicación.
En los tipos de servicios mencionados arriba, solo en el escenario de la capa de imágenes de mapa se puede restringir realmente el acceso de los usuarios a los datos. Como el medio de transmisión de los datos es a través de una imagen renderizada, no se dispone de atributos ni geometrías específicas.
Cuando los datos y los servicios se hacen públicos, aún existen varios métodos por los que se puede aplicar cierto nivel de restricción al servicio, para reducir el número de usuarios o la exposición pública.
La limitación basada en referencias es un patrón común a la hora de restringir el uso de los datos. Esto requiere un proxy inverso u otro tipo de proxy que pueda inspeccionar las peticiones HTTP individuales al servicio y rechazar aquellas que no proporcionen un encabezado de petición Referrer de HTTP con un valor que se corresponda con una lista de permitidos. Por convención, todos los navegadores generan y envían este encabezado de solicitud de aplicaciones que solicitan recursos de otro dominio, por lo que es un método fiable para controlar el tráfico basado en navegadores.
Puede ser un método eficaz para desalentar algunos usos indebidos, pero no protege los datos por completo, ya que un encabezado de referencia puede ser fácilmente suplantado por una parte motivada o agregado a una solicitud con script o programática para permitir que la solicitud pase a través del proxy. Las claves de API de la ArcGIS Location Platform se pueden delimitar para que solo admitan dominios específicos en el encabezado del remitente y, del mismo modo, limitarse a ser utilizadas en una aplicación de ese dominio o por una parte motivada que pueda falsificar el valor de ese encabezado.
Restringir las solicitudes en función de un rango de IP de origen es otra opción para proteger el acceso. Puede permitir que se solicite un recurso de forma anónima, pero solo cuando la IP de origen de la solicitud se encuentre dentro de un rango esperado, como una red de área local o una IP externa basada en NAT para una organización. Estas restricciones pueden aplicarse a nivel de servidor web, equilibrador de carga o proxy inverso. Los filtros basados en IP también pueden ser útiles para filtrar el acceso desde determinados países o zonas geográficas, o para permitir el acceso desde un sistema concreto con una dirección IP externa fija.
El uso de una clave de API es otro método habitual para restringir la reutilización de una capa pública. Implica agregar una clave de API a cada solicitud, que es validada por una capa de administración de API o proxy inverso y rechaza las solicitudes que no incluyen una clave de API válida. Aunque este planteamiento puede evitar un simple uso indebido, es relativamente fácil para un usuario motivado identificar la clave de API que se está utilizando y reutilizarla para realizar peticiones en su propia aplicación o servicio. Las claves de API se envían desde el navegador o la aplicación cliente al servidor, por lo que siempre son visibles para el cliente y podrían ser extraídas y reutilizadas para otros fines. El mejor método para mitigar este riesgo es imponer los referenciadores permitidos en función de cada clave y monitorizar las claves en busca de usos inesperados o malintencionados.
En resumen, cuando el público deseado de una aplicación o servicio es el público en general, lo mejor es considerar que todos los datos accesibles en esa aplicación son totalmente públicos. La mayoría de las restricciones sugeridas arriba pueden sortearse y, por lo general, una persona motivada puede encontrar la forma de extraer una copia de los datos para reutilizarlos. Administrar cuidadosamente el acceso, las renuncias de responsabilidad y hacer que los datos estén disponibles a través de sitios de datos públicos, son todos ellos métodos para mitigar esta preocupación sobre compartir los datos públicamente, y a través de estas prácticas algunas preocupaciones sobre el uso inadecuado se pueden mitigar parcialmente.