Заметки
Как ограничить вебхуки по IP и времени
Как ограничить вебхуки по IP и времени: Reverse proxy, guard, собственный шлюз.
Как ограничить вебхуки по IP и времени. Основной фокус: Reverse proxy, guard, собственный шлюз.
Задача
Разобрать безопасность интеграций, вебхуков, локальных приложений или файлов.
Задача — как ограничить вебхуки по IP и времени. Reverse proxy, guard, собственный шлюз.
Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.
Как это устроено
Вебхук или локальное приложение фактически становятся техническим доступом к порталу. Важно знать владельца, scopes, IP, активность, журнал вызовов и срок жизни доступа.
Разложите сценарий на уровни: где появляется исходное значение, какой метод его меняет, кто выполняет действие и какое событие должно сработать после изменения.
Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.
Рабочий подход
Ведите реестр интеграций, логируйте входящие вызовы, закрывайте прямой доступ к обработчикам и проверяйте права пользователя перед действием. Для критичных сценариев ставьте промежуточный шлюз.
Ведите журнал с URL, методом, временем, владельцем, IP, payload и результатом. Для критичных операций добавьте идемпотентность и очередь.
На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.
Частые ошибки
Самая опасная ошибка — считать секретный URL полноценной защитой. Его могут скопировать, оставить у уволенного сотрудника или случайно засветить в логах.
- Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
- Смешивать ID разных сущностей: задачу, файл Диска, CRM-дело, товарную строку или пользователя.
- Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.