Атака через подрядчика: кто на самом деле может изменить ваш сайт
Реклама работает, посетители приходят на сайт, мониторинг не замечает перебоев. Но форма уже отправляет копии заявок постороннему получателю. Для такого вмешательства необязательно взламывать сервер: иногда достаточно доступа подрядчика, который может публиковать код на страницах.
Это условный сценарий, а не история клиента. Его суть проста: безопасность сайта зависит от всех, кто может менять его код, настройки и маршрут заявки. Команда AdminVPS разбирает, как сохранить контроль над проектом, когда с ним работают несколько внешних команд.
Сайт один, а точек управления много
Студия обновляет CMS, агентство подключает рекламные теги, сервис онлайн-чата загружает свой код, интегратор настраивает передачу заказов. Каждый участник получает определённые возможности: читать данные, менять настройки, публиковать скрипты или управлять инфраструктурой.
Размещение проекта на VPS не отменяет этих связей. Виртуальный сервер предоставляет среду для работы сайта, но безопасность проекта также зависит от приложения, учётных записей и подключённых сервисов. Перенос на другую инфраструктуру сам по себе не закроет старый доступ агентства и не уберёт опасный скрипт со страницы.
У атаки через подрядчика могут быть разные механизмы. В одном случае злоумышленник захватывает аккаунт исполнителя и использует выданные ему права. В другом — подменяет код внешнего сервиса, который сайт загружает автоматически. Во втором сценарии вашей команде необязательно совершать ошибку в момент атаки: достаточно ранее настроенной зависимости.
Поэтому вопрос «Можно ли доверять подрядчику?» стоит дополнить другим: «Что произойдёт, если его доступ окажется у постороннего?» Ответ покажет возможный масштаб проблемы — от изменения одного блока до потери контроля над всем проектом.
Три сценария, которые стоит обсудить с digital-командой
Агентство ушло, право публикации осталось
Менеджер тегов позволяет подключать аналитику и маркетинговые инструменты без постоянного участия разработчика. Но право публикации в таком сервисе — существенный доступ к поведению страниц.
В Google Tag Manager, например, можно разделить редактирование и публикацию: один специалист готовит изменения, другой выпускает их на сайт. Google также рекомендует сохранять управление аккаунтом внутри организации, а не полностью передавать его внешнему агентству.
На практике риск может выглядеть так: перед запуском рекламы агентству дали расширенные права, чтобы ускорить работу. Через полгода исполнителя сменили, но его пользователей не удалили из контейнера. Новая команда проверила счётчики и цели — старые доступы в задачу не вошли.
Если такой аккаунт скомпрометируют, посторонний получит сохранившиеся полномочия. Конкретные последствия зависят от настроек контейнера, доступных типов тегов и защиты сайта.
Публикация маркетингового кода должна проходить понятную проверку. Эти права не становятся менее значимыми из-за того, что ими пользуется специалист по рекламе.
Виджет отключили, а скрипт остался
Онлайн-чат, рекомендательный блок или другой сервис может загружать JavaScript со своего адреса. Поставщик способен обновлять этот файл, даже когда ваша команда ничего не меняет в CMS.
Если скрипт выполняется непосредственно в контексте страницы, он может взаимодействовать с её содержимым, включая доступные ему поля формы. У виджета, изолированного в отдельном iframe, возможности отличаются: значение имеют способ подключения и ограничения браузера. Поэтому утверждение «любой чат видит все данные сайта» некорректно — проверять нужно конкретную интеграцию.
Представим обычную рабочую ситуацию: маркетолог отказался от сервиса, кнопку чата скрыли, подписку перестали оплачивать. Но строка подключения осталась в шаблоне сайта. Виджета посетитель уже не видит, а запрос к внешнему ресурсу по-прежнему выполняется.
Такую зависимость легко потерять из виду. Поэтому при отказе от инструмента нужно проверять не только его кабинет и внешний вид страницы, но и фактическое отключение кода.
Проект завершён, доступ разработчика действует
После запуска сайта временная учётная запись нередко становится постоянной. Особенно если штатный сотрудник, студия и приглашённый специалист работали под одним логином.
Проблема не обязательно в недобросовестности исполнителя. Его устройство или аккаунт могут скомпрометировать позже. Если доступ сохранился, завершение договора ничего не меняет технически.
Удаления пользователя из CMS тоже бывает недостаточно. Отдельно существуют доступы к серверу, репозиторию, системе публикации, API и панели хостинга. Закрытие проекта должно включать проверку всех этих способов управления.
Все три примера — типовые сценарии, а не описания конкретных инцидентов.
Почему бизнес может заметить проблему не сразу
Недоступный сайт виден сразу. Подмена получателя заявки или незаметное изменение страницы могут дольше оставаться без внимания.
Реклама продолжает приводить посетителей, но часть обращений не доходит до менеджеров. Команда меняет объявления и аудитории, хотя причина находится между формой и CRM. Если затронуты события аналитики, решения могут приниматься ещё и по искажённым данным.
При этом падение конверсии само по себе не доказывает атаку. Причиной бывают ошибки релиза, сбой интеграции или изменение спроса. Вывод другой: проверять нужно весь пользовательский путь, а не только открытие главной страницы.
Контрольная заявка должна появиться в нужной системе и попасть ответственному сотруднику. Для магазина стоит отдельно проверять оформление заказа и согласованность его статуса с платёжной системой. Такие проверки помогают обнаруживать нарушения процесса, хотя не заменяют анализ безопасности.
Цена проблемы складывается не только из восстановления сайта. Это ещё и оплаченный трафик, потерянные обращения, время команды на поиск причины и необходимость объяснять клиентам, что произошло.
Составьте карту доступов и зависимостей
Начать стоит со встречи владельца сайта, маркетолога, разработчика и ответственного за инфраструктуру. Её задача — восстановить фактическую картину управления проектом.
Для каждого сервиса зафиксируйте, кто контролирует аккаунт, кому выданы права, какие действия разрешены и зачем нужен доступ. Пароли и ключи в такую таблицу помещать не нужно.
У каждого доступа и внешнего сервиса должен быть ответственный внутри компании.
Проверяйте не только CMS. В карту должны попасть домен и DNS, панель хостинга, сервер, менеджер тегов, репозиторий, интеграции с CRM и хранилище резервных копий. Отдельно отметьте внешние скрипты: для влияния на сайт их поставщику необязательно иметь вашу учётную запись.
Приоритет определяйте по возможному ущербу. Просмотр отчётов и возможность изменить настройки домена — разные уровни риска, даже если оба доступа принадлежат одному подрядчику.
Пять вопросов для встречи по доступам
- Кто может менять сайт? Учтены ли агентства, фрилансеры, бывшие сотрудники и субподрядчики?
- Кто может публиковать без проверки? Где подготовка изменений и их выпуск находятся в одних руках?
- Что подключено извне? Какие скрипты и интеграции работают на страницах заявки, заказа и оплаты?
- Как закрыть конкретный доступ? Можно ли отключить одного исполнителя или сервис, сохранив остальную работу?
- Кто вернёт сайт в работу и проверит, что заявки снова доходят до отдела продаж?
Если ответ звучит как «это знает бывший разработчик», перед вами уже конкретная задача по возвращению контроля.
Выдавайте права под задачу и срок
Контент-редактору обычно не требуется управление сервером, а специалисту по рекламной аналитике — экспорт клиентской базы. Принцип минимальных привилегий означает, что человеку разрешают необходимые для работы действия и пересматривают полномочия при изменении задач.
Вместо общего логина нужны персональные учётные записи. Они позволяют отдельно закрыть доступ одному исполнителю и связать изменения с пользователем, если сервис ведёт соответствующий журнал. Для важных аккаунтов следует включить многофакторную аутентификацию. Она снижает риск входа по украденному паролю, но не делает избыточные права безопасными.
Доступ для разовой работы лучше выдавать с ограничением срока, если система это поддерживает. Иначе сразу назначать дату ручного отзыва. Завершением задачи должно считаться не только принятие результата, но и закрытие ненужных полномочий.
При передаче администрирования серверов внешней команде закрепите границы работ: кто обновляет серверное ПО, кто поддерживает CMS и расширения, кто проверяет резервирование. Услуга администрирования не означает автоматически, что исполнитель контролирует все маркетинговые кабинеты и интеграции компании.
Проверяйте изменения до публикации
Опасная ситуация возникает, когда один внешний аккаунт может без проверки изменить критичный участок сайта и сразу выпустить результат для посетителей.
Порядок контроля зависит от масштаба проекта. Небольшому сайту может хватить согласования изменений и проверки вторым специалистом. Для магазина с регулярными релизами полезны тестовая среда, история изменений и ограниченный круг сотрудников с правом публикации. В тестовой среде по возможности используйте синтетические или обезличенные данные.
Для внешних скриптов технической команде стоит оценить Content Security Policy — правила, которыми сайт ограничивает загрузку ресурсов и другие действия браузера. Проверку политики можно начать в режиме Report-Only: он собирает сообщения о нарушениях без блокировки. Это помогает выявить несовместимости до включения ограничений.
Для подходящих статических файлов есть Subresource Integrity: браузер сверяет содержимое с ожидаемым хешем. Но механизм требует учёта обновлений и условий загрузки; его нельзя без проверки применить ко всем меняющимся маркетинговым скриптам.
CSP и SRI — инструменты контроля зависимостей, а не кнопка «сделать безопасно». Разрешённый источник тоже может быть скомпрометирован, а неверная настройка защиты — нарушить работу формы или виджета.
Попросите техническую команду объяснить, что именно защищают выбранные меры, где заканчиваются их возможности и кто отвечает за настройку. Это должно быть понятно человеку, который принимает решения о работе сайта.
Руководителю достаточно поставить три вопроса: какие внешние компоненты работают на критичных страницах, какие данные им доступны и как отключить конкретную интеграцию при подозрении на инцидент?
Проверяйте возможность восстановления, а не наличие архива
Резервная копия полезна, если она сохранилась, пригодна для восстановления и содержит нужные данные. Архив на том же сервере, доступный тем же учётным данным, может пострадать вместе с рабочим сайтом.
При настройке резервного копирования выясните, что сохраняется: файлы, база данных, конфигурация, необходимые для запуска компоненты. Отдельно проверьте права на удаление копий. Размещение в другом хранилище ещё не отвечает на вопрос, сможет ли скомпрометированный аккаунт уничтожить и их.
Для бизнеса важны два ориентира: какой объём последних изменений допустимо потерять и сколько времени проект может восстанавливаться. Если заказы поступают непрерывно, копия базы раз в сутки может не соответствовать требованиям магазина.
Проверочное восстановление проводят в изолированной среде, без реальных списаний и рассылок клиентам. После запуска проверяют формы, заказы и интеграции. Восстановленные файлы сами по себе ещё не означают возвращения продаж.
Бэкап также не отменяет произошедшую утечку. Перед возвратом сайта в работу нужно устранить исходный путь проникновения, иначе проект может быть атакован повторно.
Договоритесь о действиях до инцидента
В договорённостях с подрядчиком нужны конкретные действия: кому он сообщает о компрометации, в какой срок после обнаружения и кто доступен вне рабочего времени. Отдельно определите порядок привлечения субподрядчиков, передачи проекта и отзыва доступов.
Если инцидент произошёл, назначьте одного координатора. Технической команде нужно ограничить подозрительный доступ или компонент, сохранить доступные журналы и историю изменений. Простое удаление обнаруженного файла может убрать симптом, оставив другой способ входа.
Проверьте связанные ключи и токены — технические учётные данные, которыми сервисы обращаются друг к другу. Их может потребоваться отозвать и выпустить заново: смена пароля пользователя не гарантирует прекращения всех подключений.
У маркетинга своя задача: оценить, безопасно ли продолжать вести посетителей на затронутые страницы. При подтверждённом нарушении оформления заказов или риске для посетителей соответствующие кампании стоит приостановить до проверки. Возобновление трафика должно опираться на работающий пользовательский путь, а не только на сообщение «сервер доступен».
Контроль остаётся внутри компании
Разработку, рекламу и эксплуатацию сайта можно передать разным исполнителям. Но внутри компании должен оставаться ответственный, который понимает, кто способен менять проект, какие внешние компоненты в нём работают и как ограничить их влияние.
Результат этой работы вполне конкретен: ненужные доступы закрыты, публикации имеют ответственных, зависимости учтены, восстановление проверено. Подрядчики продолжают выполнять свои задачи, а компрометация одного участника получает меньше возможностей затронуть весь бизнес.
Карту доступов стоит пересматривать при смене подрядчика, подключении нового сервиса и по установленному графику. При каждой проверке нужно сверять выданные права с текущими задачами и закрывать ненужные.
С чего начать: выберите один критичный путь — заявку, заказ или оплату — и проверьте его целиком. Кто может изменить страницу, подключённый код, получателя данных и интеграцию? Назначьте ответственного за каждую найденную зависимость и закройте доступы, которым больше нет рабочего объяснения.