Распространение черных списков: Как один подтвержденный случай злоупотребления может уничтожить всю сеть (RU)

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

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

Anthropic описал именно эту динамику в своем отчете за февраль 2026 года о кампаниях дистилляции — прокси-сети, которая «одновременно управляла более чем 20 000 мошеннических аккаунтов», заменяя их по мере удаления. Удаление не было узким местом. Восстановление было дешевле удаления.

Решение состоит в том, чтобы принудительное воздействие осуществлялось на идентификаторы, а не на учетные записи. API Списков Didit построен на одном механизме, который делает это за один вызов.

Основные выводы

• Внесение в черный список с помощью reference_session_id позволяет Didit автоматически извлекать нужное значение из сессии — лицо, документ, телефон, email, IP или устройство — помечать базовую модель как занесенную в черный список и связывать запись с исходной сессией.
• 12 типов записей: face (лицо), document (документ), phone (телефон), email (электронная почта), ip_address (IP-адрес), device_fingerprint (отпечаток устройства), wallet_address (адрес кошелька), bank_account (банковский счет), user (пользователь), business (компания), country (страна), key (ключ).
• Черные списки создаются системой, по одному на каждый тип записи, и являются неизменяемыми. Вы не можете их создавать, что делает принудительное воздействие единообразным.
• Записи вступают в силу немедленно во время верификации. Удаление записи разблокирует совпадение.
• ip_address принимает диапазон CIDR, поэтому вы можете заносить в черный список инфраструктуру, а не отдельный адрес.
• Белые списки по тем же 12 типам позволяют надежным разработчикам избежать всех путей эскалации.

Два важных типа списков

API имеет три типа списков, и различие между ними преднамеренно.

Черные списки создаются системой — по одному на каждый тип записи — и являются неизменяемыми. Вы не можете их создавать, переименовывать или удалять. Вы добавляете и удаляете записи. Это ограничение является функцией: оно означает, что «занесено в черный список» имеет ровно одно значение во всей вашей организации, и нет способа получить четыре конкурирующих черных списка лиц, которые разные службы проверяют непоследовательно.

Белые списки вы можете создавать сами. Сюда входят известные хорошие устройства, диапазоны адресов, бизнес-сущности и пользователи.

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

# Найти черный список лиц
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

Важный механизм

Вот обычный способ занести что-либо в черный список, и он почти всегда неправильный в реальных ситуациях:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Это заносит в черный список один адрес. Между тем, сессия, которую вы исследовали, также содержала лицо, номер документа, телефон, электронную почту и отпечаток устройства — каждый из них является идентификатором, который оператор должен заменить, прежде чем вернуться.

Лучший вызов:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Передайте reference_session_id, и Didit автоматически извлечет правильное значение для типа записи этого списка из сессии, пометит базовую модель как занесенную в черный список и свяжет запись с сессией, чтобы консоль могла показать вам, откуда она взялась.

Из этого вытекают три вещи, и все три важны с операционной точки зрения:

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

Сохраняется происхождение. Каждая запись связана с сессией, которая ее оправдала. Когда кто-то через четыре месяца спрашивает, почему это устройство заблокировано, ответ находится в один клик, а не является археологическим проектом.

Принудительное воздействие повторяемо. Тот же вызов для каждого черного списка по типу записи охватывает всю поверхность идентификатора сессии.

Если сессия содержит несколько экземпляров одного и того же типа, передайте value вместе с reference_session_id для устранения неоднозначности.

Вы также можете осуществлять принудительное воздействие вне сессии верификации. reference_object_uuid вместе с metadata.reference_type — transaction (транзакция), vendor_user (пользователь поставщика) или vendor_business (бизнес поставщика) — заносит в черный список из транзакции или от пользователя/бизнеса поставщика и сохраняет ту же связь с источником.

12 типов записей

Тип записи	Блокирует	Примечания
face	Человека	Также загружается напрямую через загрузку лица
document	Удостоверение
phone	Номер	Автоматически нормализуется до E.164
email	Адрес
ip_address	Адрес или диапазон	Принимает CIDR, например, 10.0.0.0/8
device_fingerprint	Машину	Минимум 8 буквенно-цифровых символов
wallet_address	Адрес в блокчейне
bank_account	Счет
user	Запись пользователя
business	Сущность
country	Юрисдикцию
key	Пользовательский ключ

Два из них стоит выделить для этой проблемы.

ip_address принимает диапазон CIDR. Занесение в черный список 203.0.113.0/24 блокирует инфраструктуру, а не один адрес. Когда фермерская операция работает в арендованной подсети, это разница между масштабируемым принудительным воздействием и принудительным воздействием, играющим в «ударь крота». Используйте его осторожно — диапазон охватывает и реальных пользователей, и слишком широкие диапазоны — это способ незаметно заблокировать мобильного оператора страны.

face поддерживает прямую загрузку. Если у вас есть изображение, но нет сессии, загрузите его напрямую:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Didit извлекает биометрические данные. С этого момента это лицо проверяется при каждой верификации.

Что происходит после добавления записи

Добавление в системный черный список блокирует будущие совпадения немедленно во время верификации. Нет задержки распространения и пакетной обработки.

При следующей верификации принудительное воздействие проявляется в виде предупреждений:

• FACE_IN_BLOCKLIST — окончательное совпадение, верификация отклонена. POSSIBLE_FACE_IN_BLOCKLIST — это пограничное совпадение ниже жесткого порога, и оно должно быть направлено на рассмотрение, а не на отклонение.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — совпадения сети и устройства.

В Face Search совпадение с черным списком — это единственное, что устанавливает status на "Declined". Каждое совпадение в ответе также содержит is_blocklisted, поэтому расследование сразу показывает, какие части кластера уже находятся под принудительным воздействием, а какие еще активны.

Удаление симметрично: удаление записи разблокирует соответствующую сущность. Принудительное воздействие обратимо по замыслу, что важно, потому что чрезмерно широкое принудительное воздействие является реальным риском, и вам нужен чистый путь назад.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Белые списки: защита нужных разработчиков

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

Внесите в белый список IP-диапазоны офисов партнера по дизайну. Внесите в белый список устройства инженерной команды корпоративного клиента. Внесите в белый список проверенную бизнес-сущность, чтобы ее пользователи никогда не попадали на путь эскалации. IP_ADDRESS_IN_ALLOWLIST и DEVICE_FINGERPRINT_IN_ALLOWLIST срабатывают при совпадении, поэтому вы можете подтвердить применение исключения, а не предполагать, что оно было применено.

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

Ошибки, которые стоит обрабатывать

• 400 — значение не прошло валидатор типа записи, list_type неверен для операции (например, загрузка лица в список, не относящийся к лицам), или reference_session_id не содержит данных запрошенного типа. Последний случай распространен и безвреден: не каждая сессия захватывает каждый идентификатор.
• 403 — {"detail": "You do not have permission to perform this action."}

Обратите внимание, что 400 от «сессия не содержит данных этого типа» ожидается, когда вы циклически просматриваете сессию по всем черным спискам по типам записей. Обработайте это как пропуск, а не как сбой.

Рабочий процесс принудительного воздействия

Аналитик подтвердил злоупотребление учетной записью acct_8842.

1. Сначала разрешите кластер. Face Search по лицу сессии возвращает двенадцать учетных записей; корреляция устройств и IP-адресов добавляет еще дюжину. Принудительное воздействие до разрешения блокирует одну учетную запись и предупреждает оператора.
2. Занесите в черный список из подтвержденной сессии — reference_session_id для черных списков лица, устройства, IP, электронной почты, телефона и документа. Шесть вызовов, без ручного извлечения, с полным происхождением.
3. Рассмотрите диапазон. Если сетевые доказательства указывают на арендованную инфраструктуру, запись CIDR охватывает подсеть. Сначала проверьте, что еще там находится.
4. Действуйте в отношении кластера в соответствии с вашей собственной политикой — учетные записи, которые вы уже идентифицировали, не разблокируются сами по себе.
5. Проверьте принудительное воздействие. Повторно запустите поиск лица. Совпадения теперь должны содержать is_blocklisted: true.
6. Дождитесь попытки восстановления. Следующая учетная запись, созданная с этим лицом, устройством или подсетью, будет отклонена при верификации вместо того, чтобы появиться в вашем трафике через три недели.

Шаг 6 — это весь смысл. Стоимость возвращения оператора больше не «создать новый адрес электронной почты». Это «приобрести новое оборудование, новую сеть и нового человека».

Случаи использования

Платформы AI API, преобразующие подтвержденный случай дистилляции или злоупотребления в принудительное воздействие по каждому идентификатору, с которым работал оператор.

Злоупотребления пробными версиями и кредитами, когда одно и то же устройство и лицо постоянно возвращаются за новым бесплатным выделением.

Торговые площадки, блокирующие удаленных продавцов от повторной регистрации под новым бизнесом.

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

Часто задаваемые вопросы

Могу ли я создать свой собственный черный список?

Нет. Черные списки создаются системой, по одному на каждый тип записи, и являются неизменяемыми — вы добавляете и удаляете записи. Вы можете свободно создавать белые и пользовательские списки. Это ограничение позволяет «занесенному в черный список» означать одно и то же везде.

Как быстро запись вступает в силу?

Немедленно, при следующей верификации.

Что, если я по ошибке занесу что-то в черный список?

Удалите запись, и сущность будет разблокирована. Вот почему происхождение имеет значение — каждая запись, созданная из сессии, связана с ней, поэтому вы можете проверить, для чего была запись, прежде чем удалять ее.

Влияет ли занесение диапазона IP-адресов в черный список на законных пользователей в этом диапазоне?

Да, и это риск. Запись CIDR блокирует все, что находится внутри нее. Используйте диапазоны, когда доказательства указывают на выделенную инфраструктуру, в противном случае используйте отдельные адреса и сначала внесите в белый список известные хорошие диапазоны.

Могу ли я занести в черный список что-то, что не является сессией верификации?

Да. reference_object_uuid плюс metadata.reference_type (transaction, vendor_user или vendor_business) охватывает транзакции и пользователей или бизнесы поставщиков.

Останавливает ли это извлечение моделей?

Нет. Это мешает конкретному известному актору повторно войти через идентификаторы, к которым вы применили принудительное воздействие, и это повышает стоимость восстановления. Выявление извлечения в первую очередь — задача вашего уровня трафика, а ограничение того, что дает извлечение, — задача вашего уровня модели. Это исполнительное звено трехслойной защиты, а не замена двух других.

Готовы начать?

API списков доступен для каждой учетной записи Didit.

• Прочитайте документацию — обзор API списков и каталог предупреждений об IP и устройствах.
• Посмотрите продукт — Верификация пользователя.
• Проверьте цены — публично указаны, оплата за успешные проверки, без минимумов.
• Начните бесплатно — business.didit.me, 500 KYC проверок в месяц бесплатно.