Categories: Агрегаторы

Безопасность агрегатора. Риски маркетплейса

Безопасность агрегатора – это общий вопрос, поэтому мы рассмотрим его для объектов, на которых необходимо обеспечить безопасность. Затем для каждого объекта мы определим возможные угрозы и меры их предотвращения. Тем самым мы коснемся темы рисков портала.

Кто защищен – тот вооружен!

Безопасность агрегатора: объекты защиты и возможные угрозы

Объекты для защиты сайта:

  • физический сервер,
  • система управления базами данных,
  • веб-сервер,
  • исходный код веб-приложения,
  • внешние сервисы, с которыми у движка маркетплейса есть интеграция.

Какие бывают угрозы? Обычно говорят о:

  • раскрытии секретных данных (нарушена конфиденциальность),
  • несогласованности данных в системе (нарушена целостность данных),
  • отказе сервиса в обслуживании (нарушена доступность).

Также помните о субъектах, от которых может исходить опасность:

  • персонал разработки маркетплейса (администраторы, менеджеры, операторы),
  • разработчики, системные администраторы, продвиженцы (SEO-специалисты),
  • хостер-компания,
  • поставщики услуг для маркетплейса (телефония, банкинг и т.п.),
  • пользователи портала,
  • конкуренты.

Внедряем карту угроз агрегатора (маркетплейса)

На основании анализа данных о возможных угрозах и объектах защиты составляется карта угроз маркетплейса. Каждая угроза имеет свой сценарий реализации. Ваша задача – внедрить адекватные меры противодействия этим угрозам. Вы можете сделать карту угроз цветной. Например, текущие критические необработанные угрозы помечать красным, а обработанные и нейтрализованные – зеленым.

Итак, пошагово внедряем карту угроз для защиты портала:

  • 1-ый шаг – составляем карту угроз,
  • 2-ой шаг – принимаем конкретные меры,
  • 3-ий шаг – последовательно внедряем меры,
  • 4-ий шаг – периодически пересматриваем карту угроз.

Превентивные меры по защите агрегатора

Часто говорят: “Будут проблемы – будем их решать”. В некоторых случаях такой подход может откинуть вас на пару лет назад (например, у хостера полетел жесткий диск, и вы потеряли все данные о пользователях и заказах за 5 лет). Конечно, будут некоторые угрозы, которые находятся вне вашей сферы влияния. Но в любом случае вы должны представлять, что будете делать в случае реализации этой опасности, а самые критичные риски необходимо сразу продумать и максимально нейтрализовать.

Если у вас пока нет своего агрегатора, но вы планируете его создавать, то рекомендуем изучить Как создавать концепцию проекта маркетплейса.

Руслан Раянов

Recent Posts

Форма теста внешних действий #falconstart

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Концепция внешних действий – telegram, email, уведомления на сайте

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Работа с JSON в SQL #falconstart

После выполнения действий в SQL на клиенте иногда возникает необходимость что-то обновить или сделать. Для…

3 недели ago

Форма с отправкой запроса API. Тестирование исходящих запросов #falconstart

Вы можете обратиться к внешним API через использование Внешних действий (код apirequest, использование описано в…

3 недели ago

Таблица Trace для отслеживания событий на сайте

В системной таблице as_trace хранятся данные по работе приложения. Поле code определяет тип события: DBLREQ…

3 недели ago

Работа с ошибками в системе. Генерация отчета по ошибкам #falconstart

Рассмотрим механизм анализа ошибок, как это всё работает, и как его использовать. Когда происходит ошибка…

4 недели ago