- Платёжный сервис отправляет событие о заказе во внутренний платёжный модуль.
- Система хранения кода отправляет события репозитория во внутренний сервис автоматизации.
- CRM или система поддержки уведомляет закрытую внутреннюю систему о действии клиента.
- Ваш внешний сервис передаёт рабочие события во внутренний обработчик, не открывая его в интернет.
Webhook-коннектор С сопровождением
Принимайте внешние webhook-события во внутреннем сервисе
Webhook-коннектор даёт внешнему сервису адрес BusinessProxy для отправки событий, а ваш внутренний сервис остаётся за межсетевым экраном. Локальная утилита сама подключается к BusinessProxy и передаёт принятые события только на заранее заданный внутренний адрес.
Это отдельный режим коннектора для уведомлений между системами. Он не даёт пользователю браузера доступ во внутреннюю сеть и не заменяет основной коннектор App Gateway.
Назначение
Когда это нужно
Используйте его, когда внешняя система должна уведомить внутреннее приложение, но открывать входящий порт к этому приложению рискованно или неудобно.
Путь события
Как проходит событие
Создайте webhook-коннектор
У коннектора свой тип и свой токен. Он не может публиковать приложения App Gateway, а токен App Gateway не может читать webhook-события.
Добавьте адрес приёма
BusinessProxy создаёт публичный webhook-адрес с длинным случайным секретом и связывает его с одним фиксированным внутренним адресом, списком методов, лимитом размера, временем ожидания и частотой запросов.
Укажите адрес во внешнем сервисе
Внешний сервис отправляет события на адрес BusinessProxy. Внешний запрос не выбирает внутренний адрес назначения.
Запустите локальную утилиту
Утилита сама обращается к BusinessProxy, получает принятые события только для своей рабочей области и коннектора и передаёт их на фиксированный внутренний адрес.
Безопасность
Границы безопасности
- Токены webhook-коннектора и адресов приёма отделены от токенов App Gateway.
- Внутренний адрес закреплён в настройках BusinessProxy, а не передаётся во входящем запросе.
- Метод, размер тела, время ожидания и частота запросов проверяются до постановки события в очередь.
- Секрет из публичного webhook-адреса удаляется из журналов, ошибок и экранов событий.
- Исходящее обращение использует те же защитные проверки: закрепление результата DNS, запрет служебных адресов и отказ при несовпадении цели.
Инструкция
Порядок настройки
Точные команды показываются в аккаунте и в инструкции по настройке. На уровне продукта порядок такой:
1. Создайте коннектор
В рабочей области создайте Webhook-коннектор и сохраните одноразовый рабочий токен в надёжном месте.
2. Создайте адрес приёма
Выберите тип внешнего сервиса, фиксированный внутренний адрес, разрешённые методы, лимит тела, время ожидания и ограничение частоты. Сохраните публичный адрес и одноразовый секрет.
3. Запустите утилиту рядом с внутренним сервисом
В сетевом сегменте, где доступен внутренний адрес, проверьте настройки, выполните диагностику и затем запустите процесс коннектора.
4. Настройте внешний сервис
Укажите webhook-адрес BusinessProxy во внешнем сервисе и не отключайте проверку подписи на стороне вашего приложения, если внешний сервис её поддерживает.
5. Проверьте и обновляйте секреты
Отправьте проверочное событие, убедитесь, что внутренний сервис его получил, и заранее определите порядок обновления или отзыва токенов и webhook-секретов.
Границы применения
Для чего это не подходит
- Это не общий входящий туннель во внутреннюю сеть.
- Это не доступ людей через браузер. Для этого используйте App Gateway.
- Он не доказывает сам по себе, что платёж или деловое действие действительно состоялись. Ваше приложение должно проверять важные события у исходного сервиса.
- Его нельзя использовать для доступа к произвольным внутренним адресам, выбранным отправителем.