Я думаю, что акцент на том, как «невозможно» помешать целеустремленному и технически подкованному пользователю отсканировать веб-сайт, слишком велик. @Drew Noakes заявляет, что веб-сайт содержит информацию, которая в совокупности имеет некоторую «ценность». Если на веб-сайте есть сводные данные, которые легко доступны неограниченным анонимным пользователям, то да, предотвращение очистки может быть почти «невозможным».
Я бы предположил, что проблема должна быть решена не в том, как запретить пользователям собирать сводные данные, а в том, какие подходы можно использовать для удаления совокупных данных из публичного доступа; тем самым устраняя цель скребков без необходимости делать «невозможное», предотвращая утилизацию.
Сводные данные должны рассматриваться как конфиденциальная информация компании. Информация о частной компании в целом не доступна публично анонимным пользователям в обобщенном или необработанном виде. Я бы сказал, что решение по предотвращению взятия ценных данных состояло бы в том, чтобы ограничить и ограничить доступ к данным, а не предотвратить их удаление при представлении пользователю.
1] Учетные записи пользователей / доступ - никто никогда не должен иметь доступ ко всем данным в течение определенного периода времени (в зависимости от данных / домена). Пользователи должны иметь возможность доступа к данным, которые имеют к ним отношение, но, как видно из вопроса, ни у одного пользователя не будет законной цели запросить все совокупные данные. Не зная специфики сайта, я подозреваю, что законному пользователю может понадобиться лишь небольшое подмножество данных в течение некоторого периода времени. Запрос, который значительно превышает типичные потребности пользователя, должен быть заблокирован или альтернативно ограничен, чтобы сделать очистку непомерно трудоемкой, а отбракованные данные потенциально устарели.
2] Оперативные группы часто следят за показателями, чтобы гарантировать работоспособность больших распределенных и сложных систем. К сожалению, становится очень трудно определить причины спорадических и периодических проблем, и часто даже трудно определить, что существует проблема в отличие от нормальных эксплуатационных колебаний. Оперативные группы часто имеют дело со статистически проанализированными историческими данными, взятыми из многих многочисленных метрик, и сравнивают их с текущими значениями, чтобы помочь идентифицировать значительные отклонения в работоспособности системы, будь то время работы системы, нагрузка, загрузка ЦП и т. Д.
Аналогичным образом, запросы пользователей на данные в количествах, которые значительно превышают норму, могли бы помочь идентифицировать лиц, которые, вероятно, будут отбирать данные; такой подход может быть даже автоматизирован и даже расширен, чтобы просматривать в нескольких учетных записях шаблоны, указывающие на списание. Пользователь 1 очищает 10%, пользователь 2 очищает следующие 10%, пользователь 3 очищает следующие 10% и т. Д. Подобные шаблоны (и другие) могут обеспечить надежные индикаторы злонамеренного использования системы одним человеком или группой, использующей несколько аккаунтов
3] Не делайте необработанные агрегированные данные напрямую доступными для конечных пользователей.Здесь важны особенности, а проще говоря, данные должны находиться на внутренних серверах и извлекаться с использованием некоторого специфичного для домена API.Опять же, я предполагаю, что вы не просто обслуживаете необработанные данные, а скорее отвечаете на запросы пользователей для некоторых подмножеств данных.Например, если ваши данные представляют собой подробную демографическую демографию для определенного региона, законный конечный пользователь будет заинтересован только в подмножестве этих данных.Например, конечный пользователь может захотеть узнать адреса домохозяйств с подростками, которые проживают с обоими родителями в многоквартирных домах, или данные о конкретном городе или округе.Такой запрос потребовал бы обработки совокупных данных для получения результирующего набора данных, который представляет интерес для конечного пользователя.Было бы чрезмерно сложно очистить каждый результирующий набор данных, извлеченный из многочисленных возможных перестановок входного запроса, и полностью восстановить совокупные данные.Скребок также будет ограничен безопасностью веб-сайтов с учетом количества запросов / времени, общего размера данных результирующего набора данных и других потенциальных маркеров.Хорошо разработанный API, включающий в себя специфичные для предметной области знания, будет иметь решающее значение для обеспечения того, чтобы API был достаточно всеобъемлющим, чтобы служить своей цели, но не слишком общим для возврата больших дампов необработанных данных.
Включение учетных записей пользователей на сайте, установление базовых показателей использования для пользователей, идентификация и регулирование пользователей (или другие подходы к смягчению), которые значительно отличаются от типичных моделей использования, и создание интерфейсазапрос запрашиваемых обработанных / обработанных наборов результатов (по сравнению с необработанными совокупными данными) создаст значительные сложности для злоумышленников, намеревающихся украсть ваши данные.Может быть невозможно предотвратить удаление данных веб-сайта, но «невозможность» основана на том, что совокупные данные легко доступны для скребка.Вы не можете скрести то, что не видите.Поэтому, если ваши сводные данные не являются необработанным необработанным текстом (например, электронными книгами из библиотеки), конечные пользователи не должны иметь доступа к необработанным сводным данным.Даже в примере с библиотечными электронными книгами существенное отклонение от приемлемых моделей использования, таких как запрос большого количества книг во всей их полноте, должно быть заблокировано или ограничено.