Лучшие практики для резидентных сетевых услуг, основанных на согласии

1. Цель

Резидентные сетевые услуги (иногда называемые резидентными прокси, совместным использованием пропускной способности или сетями веб-доступа) направляют трафик бизнес-клиентов через устройства потребителей, владельцы которых согласились на участие. При надлежащей реализации данная модель опирается на информированное согласие потребителя, с одной стороны, и на строгую проверку клиентов — с другой. При ненадлежащей реализации она подвергает потребителей скрытому использованию ресурсов, а интернет — злоупотребляющему трафику.

Настоящий документ рекомендует базовые стандарты, которым должен соответствовать любой оператор в данной отрасли, в форме, пригодной для принятия законодателями, регуляторами и организациями по стандартизации. Он построен вокруг четырёх основных принципов:

• Согласие потребителя и раскрытие информации
• Защита данных потребителя
• Технические меры защиты на уровне устройства
• Проверка клиентов и предотвращение злоупотреблений

Документ завершается рекомендациями относительно того, как следует проверять соответствие требованиям и осуществлять управление этим процессом.

2. Согласие потребителя и раскрытие информации

Оператору не следует подключать устройство без информированного, утвердительного и отзывного решения его владельца.

Рекомендуемые требования:

• Утвердительное согласие. Подключение требует явного действия пользователя. Никаких предварительно отмеченных флажков. Никакого скрытого включения участия в установку, обновление или несвязанную функцию.
• Равная заметность. Варианты согласия и отказа представлены с равным визуальным весом. Отказ не должен ухудшать основную функциональность приложения-носителя сверх неполучения каких-либо поощрений за участие.
• Раскрытие информации в момент принятия решения. До подключения пользователь видит изложенное простым языком: что означает участие, что через его соединение будет исходить трафик третьих лиц и какие ресурсы устройства используются (пропускная способность, CPU, электроэнергия).
• Ссылки на условия. Прямые ссылки на лицензионные условия и политику конфиденциальности оператора непосредственно на экране согласия.
• Отзыв в любое время. Отказ от участия в один клик из настроек устройства или приложения, вступающий в силу немедленно.
• Повторное согласие при существенных изменениях. Если характер участия существенно изменяется, у существующих пользователей необходимо повторно запросить согласие, а не переводить их автоматически.

Требования к приложению-носителю. Если сеть встроена посредством SDK в стороннее приложение, от приложения-носителя следует требовать: раскрывать факт интеграции в собственных условиях обслуживания и уведомлении о конфиденциальности, представлять полный процесс получения согласия без изменений и указывать наименование оператора сети. Оператор должен нести самостоятельную ответственность перед конечным пользователем независимо от отношений по встраиванию и должен проверять каждую интеграцию на соответствие данным требованиям до запуска.

3. Защита данных потребителя

Рекомендуемые требования:

• Минимизация данных. Собирать только то, что необходимо для функционирования. Допустимо: сессионный IP, анонимный идентификатор устройства, приблизительное (на уровне города) местоположение, характеристики устройства, статистика по пропускной способности.
• Запрещённый сбор. История просмотров, использование приложений, содержимое файлов, личные сообщения, точное местоположение по GPS.
• Предельный срок хранения. Данные на стороне участника удаляются по короткому фиксированному графику (60 дней являются достижимым отраслевым ориентиром), при этом эксплуатационные журналы хранятся только в той мере, в какой этого требуют меры безопасности и законодательство.
• Отсутствие вторичного использования. Данные участников не продаются и не используются в целях, выходящих за рамки функционирования сети.

4. Технические меры защиты на уровне устройства

Клиентская сессия ни при каких условиях не должна давать возможность обратиться к собственной частной сети участвующего устройства, интерфейсу обратной петли или конечным точкам облачных метаданных. Без этого клиентский трафик мог бы зондировать домашнюю сеть участника или похищать учётные данные у размещённой рядом инфраструктуры.

Рекомендуемые требования:

• Блокировка исходящего трафика в частные диапазоны. Блокировать клиентский трафик к обратной петле, частным диапазонам RFC 1918, адресам link-local и облачных метаданных, пространству NAT операторского класса, а также к эквивалентам IPv6 (link-local, unique-local).
• Контроль с учётом разрешения имён. Блокировать запрос, если любой разрешённый через DNS адрес попадает в защищённый диапазон. Проверять IP-литералы напрямую. Разворачивать и проверять адреса IPv6, сопоставленные с IPv4. Отклонять при сбое разрешения имён.
• Серверный контроль как минимальный уровень. Поскольку развёрнутое клиентское программное обеспечение обновляется медленно (циклы магазинов приложений для телевизоров и мобильных устройств могут отставать на месяцы или годы), серверный контроль, охватывающий весь трафик, должен быть обязательным. Блокировка на стороне клиента является ценной мерой эшелонированной защиты, но не может быть единственным средством контроля, поскольку устаревшие клиенты остаются в эксплуатации.
• Ограничения портов. Клиентский трафик ограничен стандартными веб-портами. Почтовые порты (SMTP и связанные) и порты удалённого администрирования (SSH, RDP, SMB, Telnet) блокируются на сетевом уровне, поскольку они позволяют осуществлять рассылку спама, атаки на учётные данные и горизонтальное перемещение.

5. Контроль злоупотреблений во время работы

Проверка проводится однократно; контроль злоупотреблений действует непрерывно. Одобренный клиент всё же может допускать нарушения, быть скомпрометированным или лишиться учётных данных в результате их хищения. Операторам следует применять эксплуатационные ограничения, которые делают сеть структурно устойчивой к злоупотреблениям независимо от того, кто ею пользуется.

Рекомендуемые требования:

• Ограничения пропускной способности на устройство. Ограничивать трафик, передаваемый любым участвующим устройством, защищая соединение участника и не допуская превращения отдельного устройства в средство атаки.
• Ограничение частоты запросов. Ограничения частоты запросов на клиента и на сессию, которые делают объёмные злоупотребления (участие в DDoS, подстановка учётных данных, агрессивные всплески сбора данных) неосуществимыми на сетевом уровне, а не просто запрещёнными на бумаге.
• Выявление аномалий трафика. Отслеживать закономерности, характерные для злоупотреблений: внезапные всплески объёма, всплески с высокой долей ошибок в отношении одной цели, распределённые схемы запросов, соответствующие известным сигнатурам атак.
• Автоматическое реагирование. Автоматически ограничивать или приостанавливать сессию клиента-нарушителя при обнаружении аномалии, при этом участвующее устройство не несёт негативных последствий.
• Аварийное отключение. Оператор должен иметь возможность немедленно остановить трафик по каждому клиенту и по каждому устройству.

6. Проверка клиентов и реагирование на злоупотребления

Меры защиты на стороне потребителя мало что значат, если любой желающий может анонимно приобрести доступ.

Рекомендуемые требования:

• Знай своего клиента до предоставления промышленного доступа. Поэтапное подключение, при котором полный доступ к сети предоставляется только после: проверки личности физического лица или идентификации организации, рассмотрения сценария использования на соответствие опубликованной политике допустимого использования, проверки бенефициарной собственности для профилей повышенного риска, подтверждения платежа и проверки по санкционным спискам (OFAC, EU, UK, UN).
• Уровни повышенного контроля. Дополнительная проверка для реселлеров, чувствительных отраслей (финансовые услуги, здравоохранение, государственный сектор), повышенных юрисдикционных рисков и сценариев использования, находящихся на границе допустимого политикой.
• Опубликованные запрещённые виды использования. Как минимум: отказ в обслуживании, распространение вредоносного программного обеспечения, CSAM (с обязательным информированием NCMEC или соответствующего национального органа), спам, подстановка учётных данных, несанкционированное сканирование и любая противоправная деятельность.
• Градуированное и документируемое применение мер. Реагирование, дифференцированное по степени тяжести, — от предупреждения до немедленного прекращения обслуживания без срока на устранение нарушения, с сохранением доказательств и передачей материалов правоохранительным органам в соответствующих случаях.
• Ответственность по цепочке договоров. Клиенты несут договорную ответственность за поведение собственных нижестоящих пользователей, благодаря чему ответственность сохраняется при перепродаже.
• Порядок взаимодействия с правоохранительными органами. Документированный приём запросов с проверкой действительности, юрисдикции и объёма; предоставление данных в строго ограниченном объёме; уведомление участника и клиента, если это юридически допустимо.

7. Как следует проверять соответствие требованиям и управлять этим процессом

Для организаций по стандартизации и схем сертификации то, как проверяется стандарт, имеет не меньшее значение, чем то, что он требует. Рекомендуемые принципы:

• Проверка по результату, нейтральная к реализации. Оценивать соответствие по тому, может ли запрещённый результат фактически наступить (например: может ли запрос к заблокированному частному диапазону фактически покинуть участвующее устройство), а не по тому, какой механизм этому препятствует. Критерии, предписывающие конкретный механизм, позволяют архитектуре одного оператора стать стандартом.
• Воспроизводимые тесты, а не коммерческие списки. Соответствие измеряется собственным документированным воспроизводимым тестом схемы. Никогда — по факту включения в блок-лист или репутационную ленту, контролируемую участником рынка.
• Надлежащая процедура до вынесения неблагоприятных заключений. Уведомление до публикации, период для представления замечаний и право на повторное тестирование. Никакого неблагоприятного включения в список по оспариваемому результату до исчерпания процедуры обжалования.
• Нейтральное управление списками. Любые критерии или блок-листы находятся в нейтральном владении, имеют версии и документированный порядок оспаривания оператором. Ни один отдельный участник или поставщик средств обнаружения их не курирует.
• Раскрытие конфликта интересов и самоотвод. Любой участник, который продаёт конкурирующие услуги обнаружения или скоринга либо находится в активном судебном споре с другим участником, раскрывает конфликт интересов и заявляет самоотвод от вынесения решений в отношении такой стороны.

8. Сводный контрольный перечень