Механика
Пять этапов: событие → нормализация → правила → инцидент → проверка. На каждом этапе — понятный вход, выход и честные ограничения.
Veriqon подписывается на доступные события портала. Каналы различаются: изменения CRM — базовый канал, web-просмотры — экспериментальный.
Вход: Действие в Bitrix24: изменение, удаление, просмотр (при доступном канале)
Выход: Сырое событие платформы
Недоступный канал не дает событий — это честно видно в матрице покрытия.
Событие приводится к платформенно-независимой модели. Телефоны и email превращаются в keyed HMAC-отпечатки, открытые значения маскируются, лишние атрибуты отбрасываются.
Вход: Сырое событие платформы
Выход: Нормализованное событие в единой модели
Полное содержимое карточек не сохраняется — только необходимое для оценки риска.
Пакеты политик проверяют события в скользящем окне: пороги, время суток, принадлежность объектов, чувствительность полей. Центр доверия исключает штатные операции.
Вход: Нормализованное событие
Выход: Сигналы сработавших правил
Пороги настраиваются; персональная поведенческая норма пока не используется — работают прозрачные абсолютные правила.
Связанные сигналы одного автора и окна объединяются в инцидент: уровень риска, факторы с источниками, хронология и затронутые объекты.
Вход: Сигналы правил
Выход: Объяснимый инцидент
Один инцидент вместо потока алертов — меньше шума, больше контекста.
Проверяющий изучает объяснение, начинает проверку, классифицирует результат — подтвержденный риск или ложное срабатывание — и закрывает инцидент. След решения сохраняется.
Вход: Инцидент со статусом «Требуется проверка»
Выход: Классифицированный и закрытый инцидент
Veriqon не выносит вердикт о виновности — решение всегда за человеком.
Пример
Демонстрация на вымышленных данных: просмотры, замены телефонов и ночная активность объединяются в инцидент «Подмена контактных данных».
INC-2026-0417
На пилоте видно, какие каналы доступны именно у вас и какие инциденты создаются на реальных процессах.