Ваше направление мысли правильное, и у нас есть идеи и наработки схожего с вашим алгоритма. Но проблема состоит в том, что приходится сталкиваться с «кричащим нарушителем», т.е. таким пользователем, который в случае своей неудачной атаки подает жалобу на нас за длительную обработку его запросов.
Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
Сейчас благодаря различным системам внутреннего мониторинга, в т.ч. благодаря государственной системе «Независимый регистратор», опровергнуть такой скрин достаточно легко.
Тем не менее, процесс все равно может растянуться, если потребуются какие-то дополнительные экспертизы и пр.
В случае начала противоборства с ботами подобная тактика может создать дополнительные накладные расходы на инфраструктуру, т.к. медленный ответ заставит систему держать все соединения/сессии открытыми.
Если речь идет о применении самоподписанных сертификатов, то это исключено. В торговых секциях по 44-ФЗ и 223-ФЗ разрешено применение только квалифицированных ЭП (и все цепочки сертификации ведут к головному УЦ страны). УЦ, с сертификатами которого можно участвовать в электронных торгах (на аккредитованных федеральных площадках), должен входить в перечень доверенных УЦ со стороны Минкомсвязи. А это, мягко говоря, не так просто сделать, т.е. сделать «УЦ-однодневку» — это очень дорогая, кропотливая и долгая работа.
C объемами данных запроса на подачу ценового предложения ничего не сделать — процедура равна стоимости типичного https-запроса. Ограничение скорости и иные лимиты применяются.
Несмотря на очевидность подобных доказательств, судебная практика в этом вопросе совсем неоднозначна. Еще совсем недавно в качестве доказательств принимались копии распечатанных (!) скриншотов, где было изображено окно браузера, в котором показывалась какая-то ошибка (самый простой пример — «500 server error»), а в адресной строке фигурировал адрес одной из наших торговых секций. По итогу таких рассмотрений судья может легко встать не на сторону площадки. То есть здесь речь больше идет не о технике, а скорее о юридической/судебной практике рынка электронных торгов. Как уже обозначали выше — у нас тут отдельный мир. Со своими нюансами, тараканами и правилами.
Лимитирование запросов — мера действенная, но ее следует использовать только в крайних случаях, т.к. у нас нет права на ошибку.
Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.
Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
Публичных списков нет, но СБ площадок стараются вести свои внутренние.
Еще скоро может появиться вот такой публичный список: Реестр участников картелей prozakupki.interfax.ru/articles/1208
Под 274 ст. попадают.
Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.
Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
Оптимизация — это же процесс практически вечный, но не всегда дающий идеальный результат.
Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.
В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).
Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.
Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
Тем не менее, процесс все равно может растянуться, если потребуются какие-то дополнительные экспертизы и пр.
Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.
Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
Еще скоро может появиться вот такой публичный список: Реестр участников картелей
prozakupki.interfax.ru/articles/1208
Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.
Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.
В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).
Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.