Кешируйте классификацию VPN и держите её возраст видимым
Наблюдение, его свежесть и ответ вашего сайта стареют с разной скоростью. Если держать их раздельно, кешированная классификация остаётся честной относительно того, что она знает.
Кешированная классификация экономит один запрос и замораживает вчерашнее мнение в сегодняшнем решении. Настоящее сравнение — не кеш против его отсутствия, а наблюдение, его свежесть и ответ, который выбрал ваш сайт. Потеряйте границу между этими тремя, и оптимизация начнёт сама творить политику. Исправление — это учёт, а не улучшенный поток.
Три записи с тремя разными часами
Наблюдение — это полученное поле, поток, из которого оно пришло, и версия набора данных за ним. Свежесть — свойство записи кеша: когда выполнялся запрос, когда записи перестают доверять и вернуло ли что-нибудь последнее обновление. Ответ — это то, что ваш сайт делает по этому поводу для этого запроса, этой учётной записи или этого действия. Их производят разные владельцы, и они разрушаются с разной скоростью, поэтому одна строка под названием blocked уничтожает различие.
| Record | Who owns it | How long it should live | Damage when it is folded into another row |
|---|---|---|---|
| The observation | the feed's operator | until a newer dataset version replaces it | a stale lookup becomes indistinguishable from a fresh one |
| Its freshness | the application | one request's tolerance for age | a failed refresh hides behind a cache hit |
| The response | whoever owns the site policy | until that policy is reviewed | a feed outage turns into an indefinite block |
Два часа заслуживают особого внимания. Момент, когда выполнялся ваш запрос, — не момент, когда поставщик опубликовал набор данных, и оператору, читающему строку позже, нужно знать, из какого из двух взято каждое значение. Задавайте срок и обновление по документированной модели обновления потока и по цене ошибки, никогда — по числу, заимствованному с другого сайта.
Храните поле, а не приговор
Документация MaxMind об анонимных IP-адресах — один конкретный пример потока, который разделяет анонимный VPN, хостинг-провайдера, публичный прокси и выход Tor на отдельные поля. Она также документирует, что незарегистрированная подсеть VPN может вместо этого всплыть под флагом хостинга. Схлопывание этого в один boolean выбрасывает единственную часть, которую оператор мог бы позже проверить.
Ни одно направление вывода не безопасно. Метка хостинга не доказывает, что использовался туннель, а отсутствие флага VPN не доказывает, что между клиентом и вашим сервисом ничего не было. Это два разных утверждения, и один boolean не может выразить ни одно из них.
Привяжите запись к адресу, который вы проверили
За обратным прокси приложение должно использовать обработку клиентского адреса, одобренную развёртыванием. Заголовок пересылки, предоставленный вызывающей стороной, никогда не должен позволять выбрать чужую кешированную репутацию.
Этот сбой — одновременно ошибка корректности и безопасности, потому что атакующий, контролирующий заголовок, может унаследовать доверенную запись или пришпилить жертву к плохой. Выводите ключ из соединения, которое завершила ваша собственная инфраструктура, и записывайте, какой вывод использовался. Когда впереди несколько прокси, документируйте цепочку, а не доверяйте первому правдоподобному заголовку. Если цепочка неоднозначна, залогируйте выведенный ключ и отклонённый заголовок, потому что именно о втором спросит разбор инцидента.
Отсутствие доказательств — не чистый результат
Тайм-аут, искажённый ответ и недоступная база данных означают каждый нечто иное, чем успешный запрос, ни с чем не совпавший. Представляйте их как отдельные исходы и заранее решите, что делает защищённое действие, когда доказательств нет вовсе. Страница только для чтения и действие в вошедшей учётной записи могут разумно следовать разным правилам.
Сохранять обычную аутентификацию или просить поддерживаемую проверку — обычно лучший ответ, чем считать сбой всеобщим разрешением или запретом для всего сайта. Ограничьте, сколько может длиться запрос, и остановите штормы обновлений тем механизмом, который поддерживает интеграция. Когда во время сбоя используется устаревшее значение, помечайте его как устаревшее в точке решения и делайте видимым последний сбой обновления, чтобы долгая неисправность не сходила за здоровую запись. Каким бы ни был выбор, записывайте его там, где применяется политика, а не в комментарии рядом с запросом.
Хранение относится к тому же решению: держите поля, нужные этой функции, и след проверки за ними, не больше. Кеш IP не обязан становиться историей просмотров.
Примите четыре случая, включая исправление
Проверьте свежий результат, истёкший результат, неудачный запрос и классификацию, которую позже исправили. Каждый упражняет отдельную ветвь, и только последний показывает, можно ли отменить ошибочное ограничение.
Затем убедитесь, что у обычного пользователя есть путь попросить пересмотр после ошибочной блокировки, потому что поток иногда будет ошибаться, а очередь — часть дизайна. Запишите четыре случая в runbook рядом с именем владельца политики. Дизайн заслуживает своего места, когда убирает лишние запросы, сохраняя неопределённость нетронутой и решение видимо принадлежащим человеку.