Когда приложение, карта или веб-сервис предоставляются через общедоступный веб-сайт или приложение (с выходом в Интернет и анонимным доступом), как правило, для обычных пользователей, часто возникает вопрос о том, как обеспечить надлежащую защиту этого доступа. Организации хотят обеспечить простой доступ для пользователей, таких как широкая общественность, не требуя аутентификации или создания учетной записи. Понятно, что они хотят быть уверены в том, что данные не будут использоваться не по назначению, не будут несанкционированно получены или сохранены этими конечными пользователями.
В большинстве рабочих процессов на основе веб-технологий клиент (часто веб-браузер) запрашивает информацию с веб-сервера, как правило, в виде изображения карты, набора пространственных объектов и атрибутов, а также растрового или векторного листа карты. В результате этих запросов формируется ответ, и он отправляется обратно клиенту, который переносит это частичное или полное представление данных на клиентское устройство, где оно используется для визуализации индикатора или изображения или обеспечения желаемого взаимодействия с картой. Рекомендации по доступу к данным приводятся вместе с общими типами сервисов.
При доступе к слоям изображений карты, также известным как динамические картографические сервисы, ответное изображение содержит только пикселы с представлением данных с определенной картографической конфигурацией. Оно генерируется на сервере и возвращается клиенту в виде изображения. Картографические сервисы можно настроить так, чтобы они разрешали только этот тип динамического изображения карты. Это делается путем отключения возможности Query запроса картографического сервиса. Это предотвратит передачу клиенту каких-либо отдельных записей данных. Однако такая конфигурация может снизить функциональность и должна рассматриваться только в том случае, если достаточно простого отображения карты.
Векторные слои могут быть созданы на основе картографических сервисов или сервисов объектов. Они отличаются от слоев изображений карты тем, что требуют, чтобы данные объекта, включая его геометрию и атрибуты, возвращались с сервера клиенту и отображались в клиентском браузере. Любой общедоступный слой объектов постоянно отправляет клиенту порции данных, которые могут представлять собой запрос на определенную географическую область или набор объектов с сервера за раз. Когда приложение использует векторный слой, клиент загружает данные, чтобы правильно их отобразить. Поскольку векторные слои полагаются на эту передачу данных клиенту, такие требования, как «Я хочу быть уверен, что пользователи не будут загружать данные», функционально несовместимы с приложением или рабочим процессом, которые зависят от векторных слоев.
Сервисы изображений позволяют пользователям динамически запрашивать определенный экстент для создания изображения. Исходное разрешение изображения может возвращать фактическое растровое представление данных вплоть до максимального размера изображения, разрешенного сервисом. Эти изображения также загружаются на клиент, например в веб-клиент, настольный или мобильный клиент, и фактически передают это подмножество данных непосредственно клиенту. Сервисы изображений также поддерживают возможность загрузки, которая по умолчанию не включена, что позволяет загружать исходное изображение или конвертированный формат. Как правило, эту возможность следует отключать, если она не требуется для работы приложения.
В описанных выше типах сервисов доступ к данным может быть действительно ограничен для пользователей только в сценарии слоя изображения карты. Поскольку данные передаются через визуализированное изображение, никакие атрибуты или специфические геометрии недоступны.
Когда данные и сервисы становятся публичными, все еще существует несколько методов, с помощью которых к сервису можно применить определенный уровень ограничения, чтобы сократить количество пользователей или раскрытие информации общественности.
Ограничение на основе рефереров — один из распространенных шаблонов ограничения использования данных. Для этого требуется либо обратный прокси, либо другой тип прокси-сервера, который может проверять отдельные HTTP-запросы к сервису и отклонять те, которые не предоставляют заголовок HTTP-запроса Referrer со значением ссылки, соответствующим разрешенному списку. По соглашению все браузеры генерируют и отправляют этот заголовок запроса от приложений, которые запрашивают ресурсы из другого домена, поэтому это надежный метод управления трафиком на основе браузера.
Это может быть эффективным методом предотвращения неправомерного использования, но не обеспечивает полной защиты данных, так как заголовок реферера может быть легко подделан заинтересованной стороной или добавлен в скриптовый или программный запрос, чтобы позволить запросу пройти через прокси. Ключи ArcGIS Location Platform API могут быть ограничены поддержкой только определенных доменов в заголовке реферера и аналогичным образом ограничены использованием в приложении на этом домене или заинтересованной стороной, которая может подделать значение этого заголовка.
Ограничение запросов на основе диапазона IP-адресов источника — еще один вариант обеспечения безопасного доступа. Он может разрешить анонимный запрос ресурса, но только в том случае, если исходящий IP-адрес для запроса находится в пределах ожидаемого диапазона, например локальной сети или внешнего IP-адреса организации на основе NAT. Эти ограничения могут применяться на уровне веб-сервера, подсистемы балансировки нагрузки или обратного прокси-сервера. Фильтры на основе IP-адресов также могут быть полезны для фильтрации доступа из определенных стран или географических регионов, а также для разрешения доступа из определенной системы с фиксированным внешним IP-адресом.
Использование ключа API — еще один распространенный метод ограничения повторного использования публичного слоя. Это включает в себя добавление ключа API к каждому запросу, который проверяется системой управления API или уровнем обратного прокси и отклоняет запросы, не содержащие действительный ключ API. Несмотря на то, что это может предотвратить простое неправомерное использование, мотивированному пользователю относительно легко идентифицировать используемый ключ API и повторно использовать его для выполнения запросов в своем собственном приложении или сервисе. Ключи API отправляются из браузера или клиентского приложения на сервер, поэтому они всегда видны клиенту и потенциально могут быть извлечены и повторно использованы для других целей. Лучший способ снизить этот риск — применять разрешенные источники ссылок-рефереров для каждого ключа и отслеживать ключи на предмет неожиданного или злонамеренного использования.
Подводя итог, можно сказать, что если желаемой аудиторией приложения или сервиса является широкая общественность, лучше всего рассматривать все данные, доступные в этом приложении, как полностью общедоступные. Большинство ограничений, предложенных выше, можно обойти, и заинтересованная сторона, как правило, может найти способ извлечь копию данных для повторного использования. Тщательное управление доступом, заявление об отказе от ответственности и предоставление доступа к данным через общедоступные сайты данных — все это методы смягчения обеспокоенности в отношении публичного распространения данных, и с помощью этих рекомендаций некоторые опасения по поводу ненадлежащего использования могут быть частично сняты.