До настройки антибота:
какие запросы к API должны быть разрешены?

1. Начните с результата одной операции

В обзоре дискуссии AM Live, подготовленном Ириной Сдобниковой, Артёму Избаенкову прямо приписаны рекомендации провести инвентаризацию ресурсов, определить, что должно быть открыто и закрыто, распределить ответственность и регулярно проверять защиту. Это полезная отправная точка для разговора о конкретном API.

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

Так у владельца продукта и специалиста по безопасности появляется общий предмет проверки. Формулировка «наш API должен работать» слишком широка. Формулировка «публичный запрос возвращает признак наличия товара, но не создаёт резерв» уже позволяет заметить разногласие до изменения правил. Это описание ожидаемого поведения, а не техническая настройка защиты.

• Обзор AM Live · Ирина Сдобникова

2. Разведите оценку трафика и разрешённое действие

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

С темой классификации связан патент RU2851682C1 «Способ классификации веб-трафика для установки защищенного соединения». Артём Избаенков — один из трёх соавторов наряду с Дмитрием Лукиным и Константином Гусевым; патентообладатель — АО «СОЛАР СЕКЬЮРИТИ». В документе описана модель с параметрами TLS и HTTP для оценки вероятности принадлежности соединения боту.

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

• Официальный PDF ФИПС · страницы 1 и 8

3. Учебный пример: проверка наличия товара

Представим вымышленный интернет-магазин. Его API возвращает только публичный признак «есть в продаже / нет в продаже» для выбранного товара. Складские остатки и резервирование в эту операцию не входят. По условиям примера магазин также договорился с одним партнёром об автоматической проверке согласованной части каталога. Это гипотетическая ситуация для обсуждения, а не кейс внедрения.

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

Запрос на резервирование товара в эту карту не попадает: у него другой результат и последствия. Для него нужна отдельная запись. Не следует переносить решение о публичном просмотре наличия на все действия с товаром.

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

4. Превратите неизвестность в конкретный вопрос

Если команда не знает, кто использует операцию, это ещё не ответ о её допустимости. Полезно записать отдельно наблюдение, предположение и недостающие сведения. Например: «видим повторяющиеся запросы» — наблюдение; «это наш партнёр» — пока предположение; «нужно сопоставить запросы с согласованной интеграцией» — следующий шаг.

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

В карте стоит оставить явное «не решено», когда доказательств недостаточно. Рядом нужны ответственный и следующий проверяемый шаг. Это полезнее, чем превращать неподтверждённое предположение в постоянное исключение или универсальное правило запрета.

5. Проверяйте изменение по ожидаемым сценариям

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

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

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

6. Закончите обсуждение одним решением

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

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