Наша почта:
В Москве:
РФ (звонок бесплатный):
Кибербезопасность крупных ecommerce проектов
{ Операционный директор }
Данила Тарасов
Видео доклада
Презентация спикера
Кибербезопасность крупных ecommerce проектов
Крупные e-commerce-проекты. Основная проблема, которую он подсвечивает, — постепенное падение квалификации IT-руководителей. Взломы публичных сервисов учащаются, утечки персональных данных, заказов доставки и такси стали регулярной новостной сводкой.
Материал построен по принципу «Вредных советов» Григория Остера: все рекомендации даны от обратного — как спроектировать интернет-магазин так, чтобы максимально облегчить жизнь злоумышленнику. Все истории под NDA, все совпадения случайны.
Материал построен по принципу «Вредных советов» Григория Остера: все рекомендации даны от обратного — как спроектировать интернет-магазин так, чтобы максимально облегчить жизнь злоумышленнику. Все истории под NDA, все совпадения случайны.
Кейс 1. Колл-центр, которому открыто всё
Вредный совет: открыть колл-центру максимальный доступ ко всем клиентским данным — это упростит работу. Неважно, собственный это колл-центр или аутсорсинговый. Показ клиентских данных ничем не ограничивать, просмотры и изменения не логировать. Количество клиентов — 300 тысяч или 4 миллиона — роли не играет.
Что было на практике. У одного из клиентов происходила утечка из колл-центра, которую очень долго не могли локализовать. Проверяли внутреннюю ERP-систему, проверяли e-commerce — заказ оформлялся, а через несколько дней его данные утекали. Причина оказалась простой: сотрудники колл-центра написали небольшой JS-скрипт, который запускали локально в консоли браузера. Поскольку по политике доступов Google Docs был разрешён, скрипт автоматически отправлял туда все данные по клиенту или заказу.
Найти это было нетривиально: сетевая безопасность утечку не видела несколько лет. Помог счётчик просмотров персональных данных: как только стало понятно, сколько записей оператор просматривает в среднем за час, аномалия вскрылась сразу — кто-то просмотрел несколько тысяч клиентов за час.
Что было на практике. У одного из клиентов происходила утечка из колл-центра, которую очень долго не могли локализовать. Проверяли внутреннюю ERP-систему, проверяли e-commerce — заказ оформлялся, а через несколько дней его данные утекали. Причина оказалась простой: сотрудники колл-центра написали небольшой JS-скрипт, который запускали локально в консоли браузера. Поскольку по политике доступов Google Docs был разрешён, скрипт автоматически отправлял туда все данные по клиенту или заказу.
Найти это было нетривиально: сетевая безопасность утечку не видела несколько лет. Помог счётчик просмотров персональных данных: как только стало понятно, сколько записей оператор просматривает в среднем за час, аномалия вскрылась сразу — кто-то просмотрел несколько тысяч клиентов за час.
Как правильно.
Учитывать внутренние сливы: даже в своей команде, где все друг друга знают, может найтись человек, который захочет выносить данные. Применять политику Zero Trust. Передавать ровно тот минимум, который нужен для действия: курьеру для звонка достаточно фамилии, телефона, номера заказа и его состава — никакой другой информации о клиенте не требуется.
Учитывать внутренние сливы: даже в своей команде, где все друг друга знают, может найтись человек, который захочет выносить данные. Применять политику Zero Trust. Передавать ровно тот минимум, который нужен для действия: курьеру для звонка достаточно фамилии, телефона, номера заказа и его состава — никакой другой информации о клиенте не требуется.
Кейс 2. Открытая папка .git в корне сайта
Вредный совет: держать .git прямо в корне сайта. Это отличный бэкап кода: не открывается GitLab, не работает Bitbucket, недоступно хранилище — зашёл на прод, скачал, всё онлайн. Достаточно запустить любой публичный дампер репозитория с GitHub (например, GitRip) — и код на локальной машине.
Что было на практике. За примерами далеко ходить не нужно: множество сайтов, в том числе старых доменов, отдают .git наружу. Ситуация напоминает недавнюю утечку, когда вместе с пакетами были опубликованы source maps и фактически открылся исходный код Claude Code.
Подвержены компании любого масштаба — от локальной розницы с десятком магазинов до FMCG-гигантов с оборотом 200 млрд рублей. В одном случае у компании с оборотом в сотни миллиардов рублей в открытом репозитории лежал не только код B2B-портала, через который общаются с клиентами, но и сертификаты, которыми подписываются push-уведомления в приложении для капитанов судов. С такими сертификатами можно отправлять любые сообщения — и они будут абсолютно валидными.
Что было на практике. За примерами далеко ходить не нужно: множество сайтов, в том числе старых доменов, отдают .git наружу. Ситуация напоминает недавнюю утечку, когда вместе с пакетами были опубликованы source maps и фактически открылся исходный код Claude Code.
Подвержены компании любого масштаба — от локальной розницы с десятком магазинов до FMCG-гигантов с оборотом 200 млрд рублей. В одном случае у компании с оборотом в сотни миллиардов рублей в открытом репозитории лежал не только код B2B-портала, через который общаются с клиентами, но и сертификаты, которыми подписываются push-уведомления в приложении для капитанов судов. С такими сертификатами можно отправлять любые сообщения — и они будут абсолютно валидными.
Как правильно.
Если сборка идёт через клонирование, удалять папку .git после сборки или использовать git archive, чтобы получить только чистый код без репозитория. Делать периодические сканы: помимо автоматических (SonarQube, Coverity, Micro Focus) — ручные проверки раз в месяц или квартал. Это 5–10 минут времени тестировщика или лида, но эффект для безопасности несоизмеримо больше. И не забывать про smoke-тесты после релиза: даже когда всё автоматизировано и проверено руками, .git в проде появляется внезапно.
Если сборка идёт через клонирование, удалять папку .git после сборки или использовать git archive, чтобы получить только чистый код без репозитория. Делать периодические сканы: помимо автоматических (SonarQube, Coverity, Micro Focus) — ручные проверки раз в месяц или квартал. Это 5–10 минут времени тестировщика или лида, но эффект для безопасности несоизмеримо больше. И не забывать про smoke-тесты после релиза: даже когда всё автоматизировано и проверено руками, .git в проде появляется внезапно.
Кейс 3. Пакеты, авторизация и забытый GitLab
Вредный совет: не тратить драгоценное время разработчика на авторизацию. Пришёл новый коллега — не выдавать доступы к репозиторию или пакету, а просто скопировать пакеты, уже содержащие авторизационные данные (npm, Yarn, Composer). Экономия времени налицо. А если вендор заблокировал скачивание уже купленных пакетов на территории — тем более стоит выложить их и помочь коллегам.
Что было на практике. Пару недель назад на сайте одной производственной компании обнаружился открытый composer.lock: точные версии пакетов видны, публичные уязвимости к ним подбираются тривиально. Открытые composer.json и composer.lock встречаются даже на сайтах, имеющих отношение к государству, — не уровня «Госуслуг», но меньшего масштаба.
Отдельная частая ошибка — необновлённый GitLab: поставили и забыли на пару лет. По GitLab выходит много security-обновлений; двухлетний экземпляр ломается по публичным CVE за пять минут с получением прав администратора.
Что было на практике. Пару недель назад на сайте одной производственной компании обнаружился открытый composer.lock: точные версии пакетов видны, публичные уязвимости к ним подбираются тривиально. Открытые composer.json и composer.lock встречаются даже на сайтах, имеющих отношение к государству, — не уровня «Госуслуг», но меньшего масштаба.
Отдельная частая ошибка — необновлённый GitLab: поставили и забыли на пару лет. По GitLab выходит много security-обновлений; двухлетний экземпляр ломается по публичным CVE за пять минут с получением прав администратора.
Как правильно.
Внедрить культуру работы с ENV: переменные задаются на серверном окружении, а код их только принимает. Это требует времени, но заметно безопаснее. Наличие нормальной работы с ENV — сам по себе показатель зрелости процесса разработки. Если внешние пакеты использовать нельзя или не хочется, можно поднять внутренний пакетный менеджер: тогда даже при утечке composer.json/lock или package.json в них будут ссылки на пакеты внутри локальной сети, недоступные снаружи.
Внедрить культуру работы с ENV: переменные задаются на серверном окружении, а код их только принимает. Это требует времени, но заметно безопаснее. Наличие нормальной работы с ENV — сам по себе показатель зрелости процесса разработки. Если внешние пакеты использовать нельзя или не хочется, можно поднять внутренний пакетный менеджер: тогда даже при утечке composer.json/lock или package.json в них будут ссылки на пакеты внутри локальной сети, недоступные снаружи.
Кейс 4. Docker-файлы и ENV в корне
Вредный совет: выложить Dockerfile и docker-compose.yml прямо в корень сайта — помочь новичкам и джунам разобраться, как устроена сборка образа. Можно пойти дальше и прописать в Dockerfile ключи деплоя, под которыми GitLab авторизуется в репозитории и выкатывает проект. А ещё удобнее — сложить все переменные окружения в env.txt и оставить его в корне: тестировать функционал прямо на проде станет намного проще.
Что было на практике. Открытый Dockerfile в корне сайта; открытый .gitlab-ci.yml с путями и авторизацией. Подвержены и розничные сети с оборотом в десятки миллиардов рублей и внутренней командой из 20 человек, и — что особенно показательно — агентства заказной разработки с большими оборотами: у них тоже встречаются открытые исходники, Docker-файлы и ENV.
Что было на практике. Открытый Dockerfile в корне сайта; открытый .gitlab-ci.yml с путями и авторизацией. Подвержены и розничные сети с оборотом в десятки миллиардов рублей и внутренней командой из 20 человек, и — что особенно показательно — агентства заказной разработки с большими оборотами: у них тоже встречаются открытые исходники, Docker-файлы и ENV.
Как правильно.
Выстраивать культуру кода и нормальный CI/CD с агентами, чтобы прямых доступов не было нигде, а сборка происходила в отдельном месте (Jenkins, Capistrano — любой деплойер), который выкладывает на прод уже готовый пакет. Регулярно проверять себя ручными тестами: раз в месяц или квартал, пять минут. ENV задаются конфигуратором окружения, а в шаблонах — только использование переменных.
Выстраивать культуру кода и нормальный CI/CD с агентами, чтобы прямых доступов не было нигде, а сборка происходила в отдельном месте (Jenkins, Capistrano — любой деплойер), который выкладывает на прод уже готовый пакет. Регулярно проверять себя ручными тестами: раз в месяц или квартал, пять минут. ENV задаются конфигуратором окружения, а в шаблонах — только использование переменных.
Кейс 5. Ошибки, которые никто не чинит
Вредный совет: сделать так, чтобы бизнес нуждался в исполнителе, — тогда его не уволят. От 2 до 10 тысяч падений и исключений в день — погрешность сбора статистики. Зато это отличный стресс-тест для Customer Support: видно, как первая и вторая линия обрабатывают тикеты. Заодно проверяется, как система логирования и серверы справляются с потоком ошибок. Править ошибки не нужно — есть более приоритетные задачи. Не оформляется заказ? Ничего страшного.
Что было на практике. В консоли ошибка видна, а если используются публичные или open-source-решения, по ней легко понять, где именно уязвимое место, и воспользоваться этим. Сеть офлайн-магазинов с большими площадями: несколько тысяч ошибок в день, изо дня в день, реакции нет никакой.
Что было на практике. В консоли ошибка видна, а если используются публичные или open-source-решения, по ней легко понять, где именно уязвимое место, и воспользоваться этим. Сеть офлайн-магазинов с большими площадями: несколько тысяч ошибок в день, изо дня в день, реакции нет никакой.
Как правильно.
Корень проблемы — квалификация IT- и e-commerce-руководства и отсутствие выстроенного окружения: не используются системы логирования и сбора ошибок (Sentry), мониторинг (Zabbix), не работают SLA и матрица ответственности RACI. Возникает закономерный вопрос, как такая система вообще живёт.
Корень проблемы — квалификация IT- и e-commerce-руководства и отсутствие выстроенного окружения: не используются системы логирования и сбора ошибок (Sentry), мониторинг (Zabbix), не работают SLA и матрица ответственности RACI. Возникает закономерный вопрос, как такая система вообще живёт.
Кейс 6. Аптайм вместо обновлений
Вредный совет: не платить за SLA, если и так всё работает. Держать высокий аптайм — это показатель стабильности сервера. Ядро и пакеты годами не обновлять, иначе придётся перезагружаться и аптайм испортится: шесть девяток после запятой так не получить.
Что было на практике. Сервер с аптаймом полтора года и ядром 2024 года — при том что по Debian в последние недели выходит масса критичных CVE. Ритейл-сеть с офлайн-магазинами и оборотом в десятки миллиардов рублей: 20 серверов, поставленных под веб три года назад, ни разу не обновлялись.
Что было на практике. Сервер с аптаймом полтора года и ядром 2024 года — при том что по Debian в последние недели выходит масса критичных CVE. Ритейл-сеть с офлайн-магазинами и оборотом в десятки миллиардов рублей: 20 серверов, поставленных под веб три года назад, ни разу не обновлялись.
Как правильно.
Multi-node-окружение: одну ноду обновили и перезагрузили, остальные приняли нагрузку. Если лишних мощностей нет — ночные перезагрузки в часы минимального трафика B2C: перезагрузили, проверили, работаем дальше. Тактика периодических ребутов работает хорошо. В Kubernetes проблема решается конфигурацией, поднимающей последнее доступное ядро автоматически. Чтобы вовремя узнавать об уязвимостях — подписаться на CVE-листы Debian Security или соответствующие рассылки.
Multi-node-окружение: одну ноду обновили и перезагрузили, остальные приняли нагрузку. Если лишних мощностей нет — ночные перезагрузки в часы минимального трафика B2C: перезагрузили, проверили, работаем дальше. Тактика периодических ребутов работает хорошо. В Kubernetes проблема решается конфигурацией, поднимающей последнее доступное ядро автоматически. Чтобы вовремя узнавать об уязвимостях — подписаться на CVE-листы Debian Security или соответствующие рассылки.
Кейс 7. Всё на одном сервере
Вредный совет: администрировать один сервер удобнее, чем много. Всё в одном месте: интеграции, расширение функционала, единый ID, сервис регистрации и сервис оплаты рядом.
Что было на практике. Сеть российских курортов: всё размещено на одном сервере. Оплата парковки идёт через веб — вводится карта, тикет уходит на ворота. Сервер падает — несколько сотен человек физически не могут выехать с территории. И никого, кто бы это чинил или хотя бы смотрел.
Что было на практике. Сеть российских курортов: всё размещено на одном сервере. Оплата парковки идёт через веб — вводится карта, тикет уходит на ворота. Сервер падает — несколько сотен человек физически не могут выехать с территории. И никого, кто бы это чинил или хотя бы смотрел.
Как правильно.
Внедрить матрицу ответственности RACI (Responsible, Accountable, Consulted, Informed) и распределить, кто за что отвечает и как реагирует. Организовать поддержку по SLA — своими силами или по контракту с компанией, обеспечивающей режим 24/7. Не хранить все яйца в одной корзине. Минимальный вариант — постоянный бэкап и схема master–slave: упал мощный продовый сервер — нагрузка переходит на slave меньшей мощности в другом сегменте дата-центра. Работать будет медленнее, но будет.
Внедрить матрицу ответственности RACI (Responsible, Accountable, Consulted, Informed) и распределить, кто за что отвечает и как реагирует. Организовать поддержку по SLA — своими силами или по контракту с компанией, обеспечивающей режим 24/7. Не хранить все яйца в одной корзине. Минимальный вариант — постоянный бэкап и схема master–slave: упал мощный продовый сервер — нагрузка переходит на slave меньшей мощности в другом сегменте дата-центра. Работать будет медленнее, но будет.
Кейс 10. Готовые модули и самописный функционал
- Вредный совет: купить готовый плагин приёма платежей в маркетплейсе — он уже проверен и надёжен, разрабатывать ничего не нужно.
Что было на практике. Купленный модуль эквайринга не проверял подпись от шлюза: не сверялась хеш-сумма ответа, не проверялось даже, что ответ пришёл по HTTPS от реального шлюза. В результате можно отправить запрос, похожий на ответ эквайринга, — и заказ в магазине получит статус «оплачен». - Вредный совет 2: авторизацию по SMS удобно отлаживать прямо на проде — возвращать код подтверждения в ответе контроллера. Тем более что при текущих ограничениях связи SMS может просто не дойти.
Что было на практике. Ритейл с миллиардным оборотом: фрод на 500 тысяч рублей в день — заказы, подтверждённые не по SMS, а через ответ контроллера. Стрелки переводились по кругу, виновных не нашли.
Как правильно.
Покупной модуль обязательно проверять — даже официально рекомендуемые банками модули нередко пишет фрилансер, а банк проверяет только, что платёж проходит, отмена проходит и одностадийная и двухстадийная схемы работают. Иногда банки и службы доставки пишут интеграции хуже фрилансеров, и результат приходится переделывать. На критичный функционал — персональные данные, приём платежей — писать тест-кейсы и прогонять их. Делать защиту от дурака: дураки были, есть и будут. И пытаться сломать собственное решение ещё на этапе проектирования.
Покупной модуль обязательно проверять — даже официально рекомендуемые банками модули нередко пишет фрилансер, а банк проверяет только, что платёж проходит, отмена проходит и одностадийная и двухстадийная схемы работают. Иногда банки и службы доставки пишут интеграции хуже фрилансеров, и результат приходится переделывать. На критичный функционал — персональные данные, приём платежей — писать тест-кейсы и прогонять их. Делать защиту от дурака: дураки были, есть и будут. И пытаться сломать собственное решение ещё на этапе проектирования.
Мониторинг внутренних угроз
Отдельного упоминания заслуживает вопрос выявления аномального поведения внутренних пользователей. По опыту, автоматические средства информационной безопасности, установленные даже у крупных международных клиентов, такие утечки не засекали вообще. Работает только нетривиальная ручная работа: максимально «тупое» логирование того, кто и какие данные использует, с последующим ручным разбором. Встречались кейсы, когда команда брала несколько десятков гигабайт access-логов веб-сервера и вручную разбирала URL с GET-параметрами, чтобы понять, как произошёл взлом.
С учётом доступности LLM ситуация обостряется: подобный скрипт сегодня способен написать практически любой оператор колл-центра. Поэтому на рабочих станциях колл-центров стоит запрещать запуск постороннего кода — но и это не панацея: в описанном выше случае запрещено было всё, кроме Google Docs, открытого по бизнес-требованию, — им и воспользовались.
С учётом доступности LLM ситуация обостряется: подобный скрипт сегодня способен написать практически любой оператор колл-центра. Поэтому на рабочих станциях колл-центров стоит запрещать запуск постороннего кода — но и это не панацея: в описанном выше случае запрещено было всё, кроме Google Docs, открытого по бизнес-требованию, — им и воспользовались.
Финал
Ключевые выводы доклада:
- Работать с профессионалами. Если решение стоит подозрительно дёшево, качественным оно не будет.
- Никому не верить: Zero Trust. Принцип default deny — запрещено всё, доступ выдаётся по чуть-чуть и только с обоснованием, зачем нужен этот функционал или эти данные.
- Не изобретать велосипед в управлении проектами. Матрица ответственности RACI, SLA с классификацией инцидентов P1–P4 и линиями поддержки L1/L2 давно описаны — достаточно взять готовый шаблон и адаптировать под свой бизнес.
- Пытаться сломать собственную архитектуру. Существует байка, что при разработке софта для ракет в NASA работали две команды: одна писала код, вторая параллельно пыталась его сломать, и примерно раз в месяц они менялись местами.
- Помнить, что сделать простую вещь хорошо намного сложнее, чем сложную — как-нибудь.
В Москве:
РФ (звонок бесплатный):
Наша почта:
GetNet
Остались вопросы?
Группа компаний VoxLink © 2011-2026