Чек-лист: как обеспечить информационную безопасность маркетплейса
Перевод процессов по предоставлению товаров и услуг в онлайн открывает перед бизнесом новые возможности: позволяет сократить эксплуатационные расходы, улучшить обслуживание клиентов и ускорить адаптацию компании к меняющимся рыночным условиям. При этом миграция в онлайн должна быть постепенной и учитывать практики информационной безопасности, чтобы исключить риски сбоев и потери данных.
The post Чек-лист: как обеспечить информационную безопасность маркетплейса appeared first on Хайтек.
О том, как обеспечить киберзащиту онлайн-сервисов и минимизировать потенциальные уязвимости, на примере маркетплейса для автолизинга рассказывает Константин Абакумов, директор дивизиона технологического развития дочерних структур группы «Иннотех» (Холдинг Т1).
Опыт из первых рук
В прошлом году мы внедрили маркетплейс для автолизинга в одной из крупнейших российских финансовых компаний. Перевод всех процессов по выбору автомобиля, подписанию договора и обмену документацией в онлайн значительно упрощает взаимодействие покупателя и продавца.
Отметим, что первичные наработки мы получили «из рук» предыдущего вендора, поэтому перед началом внедрения наши специалисты провели аудит платформы. В частности, цифровая система требует особой защиты и внимания к кибербезопасности. Команда выполнила пентесты (penetration test — тестирование на проникновение злоумышленника в контур) каждого фронтального решения, анализ всех API на случай массовой выгрузки данных и несанкционированных изменений. Специалисты изучили зависимость программных компонентов и проработали методы защиты доступа к данным в хранилищах. И в завершение — изменили архитектуру приложения для разделения демилитаризованной зоны (DMZ — Demilitarized Zone) и внутренней сети организации, чтобы предотвратить проникновение во внутренний контур. Проверка показала, что на момент запуска отсутствовал единый центр аутентификации и авторизации для клиентского и межсервисного взаимодействия, внутренний трафик не шифровался. Все это потенциально может привести к утечке данных клиентов.
Вслед за ростом активности хакеров появляются новые и совершенствуются существующие инструменты для защиты ИТ-инфраструктуры от киберугроз. Поэтому важно сделать процесс обеспечения информационной безопасности цифровых решений непрерывным. Даже после запуска продукта при каждом обновлении маркетплейса система должна проходить проверку на возможные риски.
Чек-лист: необходимые манипуляции перед запуском маркетплейса
- Статический анализ кода
- Анализ собранных пакетов
- Динамический анализ приложения
- Пентест
- Аудит ролевой модели пользователя, технического и административного специалистов (если применим)
- Настройка на уровне сетевых сегментов компании (WAP)
Как защитить сервис от киберугроз?
Основной и самый выгодный способ снизить вероятность фрода — предусмотреть возможные риски еще на этапе написания системы и автоматического сканирования после первого запуска. Если распознать возможные риски в процессе статического анализа кода (SAST), то корректировка не потребует больших временных и финансовых затрат. Чем позже удастся выявить угрозу, тем дороже обойдется ее устранение, а исправление займет больше времени. При этом нужно отметить, что на первом этапе всегда фиксируется ряд потенциальных уязвимостей, однако часть из них может оказаться false positive (ложноположительной). Это означает, что отмеченные кейсы могут быть валидны на уровне анализа кода, однако они допустимы, поскольку компенсируются другим архитектурным решением. Тогда мы можем оставить эти уязвимости, чтобы сэкономить время разработки. Соответственно, после формирования изначального отчета обо всех отмеченных угрозах идет анализ и приоритизация того, что действительно является риском, который необходимо устранить, а что — нет. Какие-то уязвимости могут даже не устраняться, если цена их удаления выше, чем потенциальный ущерб, который может быть нанесен.
Динамический анализ приложения (DAST) — это тестирование «черного ящика», которое является своего рода автоматизированным пентестом. DAST, в отличие от статического анализа, применяется только в отношении собранного и работающего приложения и позволяет выявить распространенные уязвимости безопасности, к примеру, SQL-инъекции.
Помимо написания самого приложения, есть практики уровня сетевой защиты (Wireless Application Protocol — WAP). С помощью WAP злоумышленник не сможет дойти до содержимого системы, поскольку доступ будет ограничен уже во время подключения. В оптимальном случае необходимы правильная архитектура и расположение частей сервиса в правильных зонах сетевой безопасности заказчика — так называемый внутренний контур, к которому имеют доступ только штатные сотрудники.
Последний этап — это пентест или ручной анализ системы на наличие уязвимостей. На данном уровне уже есть готовый продукт, поэтому это финальная проверка службой ИБ, когда в идеале никаких рисков уже не должно быть. В ходе пентеста выявляется вероятность взлома сервиса, из-за которого злоумышленники могут получить доступ к аккаунту клиента и его данным. Конфиденциальная информация может использоваться как с прямой целью оформления заявки на покупку машины и ее получения без оплаты, так и для других видов мошенничества. Стоит учесть, что, в отличие от статического анализа, который может выполнить команда проекта, для пентеста привлекаются узкопрофильные специалисты, обладающие достаточным уровнем экспертизы в сфере ИБ. Они должны дополнительно представить сертификат OSCP или Pentesting, который подтверждает опыт анализа продуктов.
Обложка — downloaded from Freepik.
The post Чек-лист: как обеспечить информационную безопасность маркетплейса appeared first on Хайтек.