Встроенные уязвимости встроенного страхования

Уровень конверсии в традиционном страховании (когда покупки имущества, подлежащего страхованию, и самого страхования совершаются независимо) составляет 1-3%. При использовании встроенного страхования, т.е. предложения потенциальному страхователю продукта в момент и в месте совершения (виртуальном или реальном) покупки, конверсия вырастает до 10-20%. В результате встроенное страхование становится очевидным выбором для компаний, стремящихся нарастить свой портфель имущественного, моторного и других видов страхования.
Технологической основой, без которой реализация встроенного страхования будет невозможной, является интеграция. Интеграционные интерфейсы должны гарантировать быстрый обмен данными, давая возможность страховщику провести скоринг клиента, сформировать для него предложение и отправить его обратно партнёру-продавцу, прежде чем клиент успеет заполнить все поля, необходимые для оформления заказа (при покупке онлайн).

Как и любая технология, API имеет свои уязвимости. Выделяют 3 типа таких уязвимостей:

Ролевые, т.е. неправомерный доступ пользователей к тем или иным возможностям.
Уязвимость данных, т.е. возможность выкачивания данных по причине открытого доступа к ним
Сам по себе интеграционный интерфейс, к которому также можно получить слишком полный доступ через доступный пользователям SDK.
В современных средах API отслеживание того, кто, как и когда использует API, в основном зависит от человека в ИТ, которому поручено знать всю архитектуру системы. Использование API на момент его установки могло быть совершенно безопасным. Данные перемещались из точки А в точку Б и способствовали любым транзакциям. Однако со временем системные команды могут обновить API или изменить его использование. Это может происходить на другом конце партнерской системы. Это не означает, что поток данных был отключен, просто он больше не выполняет свою первоначальную задачу. В этом случае возникают две проблемы безопасности. Данные могут попасть в чужие руки, а хакеры могут получить путь к основным системам. Все эти проблемы реальны и умножаются в компаниях, которые управляют своими собственными API непосредственно из внутренних систем, не используя при этом облачные API-платформы.

Одним из инструментов управления интеграциями, позволяющим закрыть бреши в безопасности, не жертвуя при этом функционалом, является интеграционный шлюз, работающий в сочетании с сервисом авторизации и другими, обеспечивающими должный уровень безопасности. Шлюз гарантирует, что пользователи получат доступ только к актуальным, рабочим версиям интеграционных интерфейсов и только в том объёме, который соответствует их правам.

Проще всего построить систему управления интеграциями в облаке. Это потребует от страховщиков минимума усилий как на этапе внедрения, так и в поддержке. Крупнейшие облачные провайдеры (временно недоступные в наших широтах) предоставляют стандартные интеграционные интерфейсы, специально заточенные под особенности страхового бизнеса. Про некоторые из них я писал. Но можно сделать всё то же самое и в контуре, и разработать индивидуально под потребности именно вашей компании.

Конечно, можно просто закрыть всю эту интеграцию, и тогда точно враг не просочится ни в одну внутреннюю систему. Но вы же не хотите иметь конверсию в цифровых каналах и, соответственно, продажи вдесятеро меньше возможных только из-за недостатков в управлении своими API?