# HMAC-SHA256 для подписи веб-перехватчиков DLR — как и зачем

> HMAC-SHA256 — это криптографический примитив, используемый каждой современной платформой обмена сообщениями для подписи веб-хуков, подтверждающих доставку и входящие сообщения. Платформа вычисляет хеш с ключом по телу запроса, используя общий секрет; ваша конечная точка пересчитывает тот же хеш и сравнивает его. Это доказывает, что веб-хук поступил от платформы, а не от кого-то, кто угадал ваш URL, и что тело запроса не было изменено во время передачи.

- Канонический URL: https://www.broadnet.me/ru/answers/hmac-sha256-dlr-signing
- Язык: ru
- Последняя проверка: 2026-09-24
- Издатель: BroadNet (https://www.broadnet.me)

## Как формируется подпись

Распространенная схема формирует каноническую строку `${timestamp}.${requestBody}`, вычисляет `HMAC-SHA256(canonical, secret)`, кодирует результат в hex и передает дайджест и метку времени в заголовке подписи. Метка времени внутри подписанных данных защищает от атак повторного воспроизведения — ваша конечная точка должна отклонять веб-хуки старше 5 минут. Имена заголовков и точный канонический формат различаются между платформами, поэтому уточните их у своего поставщика, прежде чем писать код проверки.

## Почему используются подписи HMAC, а не RSA?

HMAC симметричен — обе стороны разделяют секретный ключ, — что означает, что подписание и проверка примерно в 10 000 раз быстрее, чем RSA-2048. Для веб-хуков, где один SMSC может генерировать 50 000 DLR в секунду, подписание RSA занимает доминирующую долю ресурсов ЦП. HMAC-SHA256 на современном оборудовании выполняется за несколько микросекунд. Компромисс: подписать может любой, у кого есть секрет, поэтому секрет должен быть известен только платформе и вашей среде, храниться как любые другие учетные данные и ротироваться по запросу.

## Подводные камни проверки

Три распространённые ошибки. Сравнение строк с помощью `==` вместо сравнения за постоянное время (атака по времени — используйте `crypto.timingSafeEqual`). Проверка подписи после разбора тела JSON (необходимо проверять исходные байты, а не пересериализованное представление — изменение порядка JSON нарушает хеширование). Забытое окно защиты от повторного воспроизведения для временной метки.

## Помимо HMAC

Для регулируемых сред (банки, здравоохранение) некоторые платформы также поддерживают доставку веб-хуков по mTLS: отправитель предъявляет клиентский сертификат, который ваш балансировщик нагрузки проверяет до того, как запрос попадет в приложение. Это надежнее HMAC, поскольку доставка привязывается к аппаратному ключу, но оправдывает затраты только для действительно чувствительных нагрузок. Для большинства интеграций правильный ответ — HMAC-SHA256 поверх HTTPS.

## См. также

- [Все ответы](https://www.broadnet.me/ru/answers)
- [Глоссарий](https://www.broadnet.me/ru/answers)
- [TLS 1.3 в системах обмена сообщениями — что изменилось и почему это важно для SMPP](https://www.broadnet.me/ru/answers/tls-1-3-in-messaging)
- [Что такое DLR (отчёт о доставке)?](https://www.broadnet.me/ru/answers/what-is-dlr)
- [Webhook setup](https://www.broadnet.me/ru/developers/webhooks)