Безопасность сайта после увольнения сотрудника: Доступы к сайту, серверу или хостингу — это наиболее чувствительная часть инфраструктуры бизнеса, которая должна находиться под надежной защитой. Особенно важно менять их после увольнения сотрудника или подрядчика, чтобы исключить несанкционированный доступ и предотвратить возможные угрозы безопасности данных или даже ущерб репутации компании.
После смены сотрудника важно тщательно проверить сайт, чтобы убедиться в его целостности, безопасности и корректной работе.
Основные моменты для проверки:
- Смена паролей и доступов:
Обновите пароли и доступы к сайту, серверу, хостингу и административным панелям сайта, базе данных, включая подключения по FTP и SSH. Убедитесь, что бывший сотрудник лишён возможности доступа к системам. - Почта и уведомления:
Проверьте отправку email уведомлений, а так-же наличие переадресации копий на email бывшего сотрудника. - Проверка прав и ролей пользователей:
Проверьте права пользователей и роли внутри CMS — убедитесь, что они соответствуют текущему уровню доступа и нет лишних полномочий, особенно административных. - Технический аудит сайта:
Проверьте все функциональные компоненты: формы обратной связи, регистрацию пользователей, корзину, интеграции с CRM и другими внешними сервисами. Убедитесь, что все элементы работают корректно и без ошибок. - Резервное копирование:
Проверьте, что регулярно создаются резервные копии сайта и базы данных, и что они доступны для восстановления при необходимости. - Проверка контента и SEO:
Оцените состояние сайта с точки зрения контента: отсутствуют ли битые ссылки, корректны ли метатеги, не появились ли нежелательные изменения. Проверьте индексацию и видимость сайта в поисковых системах. - Аудит логов и активности:
Изучите последние логи доступа и действий в системе, чтобы выявить подозрительную активность и попытки несанкционированного доступа.
Для бизнеса важно уметь расставаться с сотрудниками без долгов и обид, при этом делать это правильно и своевременно, если возникает такая необходимость. Такой подход сохраняет хорошие отношения, помогает избежать конфликтов и минимизирует репутационные риски.
Четыре случая, где доверие стоило времени и денег, как заказчика так и для исполнителя
Реальные случаи из моей практики.
Случай 1: Забытые настройки доступа - потерянные клиенты
Поступила заявка на внесение изменений на сайте, созданном на Drupal 7. Это был сайт по продаже китайских автомобилей в России, принадлежащий китайскому владельцу.
Заявка поступила не напрямую от владельца, а от агентства, взявшего сайт в продвижение. В агентстве не было специалистов с опытом работы в Drupal, поэтому ко мне обратился исполнитель для внесения правок по его техническому заданию. Понимая, что потерять заказчика нельзя, агентство решило ограничиться только визуальными изменениями, чтобы как можно быстрее запустить рекламную кампанию.
В задачи входило добавить несколько новых блоков, обновить тексты, разместить новую карту с филиалом, изменить заголовки и немного доработать описание главной страницы.
Перед началом работы с чужим проектом я всегда провожу предварительный аудит и сразу информирую о выявленных проблемах и возможных способах их решения, особенно я уделяя внимание безопасности данных. В ходе проверки я обнаружила серьёзную уязвимость: заявки, отправляемые через сайт не проходили через стандартные веб-формы, а публиковались как отдельные материалы, права на которые были открыты для просмотра всем пользователям. Каждая новая заявка публиковалась по одной ссылке с номером страницы в возрастающем порядке. Заявки были доступны и индексировались в публичном поиске.
Проверив права доступа на редактирование материала, я обнаружила, что они предоставлены одной из менеджерских ролей, что показалось мне излишним и не безопасным. Таким образом, менеджер мог случайно или намеренно сделать заявки публичными. Такая ситуация могла возникнуть либо по ошибке, либо вследствие действий недовольного сотрудника ушедшего из компании, либо того, кто планировал использовать заявки вне бизнеса. При этом логи доступа были уже стерты по таймеру и установить кто, и когда изменил настройки, не представлялось возможным.
Информацию об этом я немедленно передала исполнителю, попросив уточнить у клиента, существуют ли у них интеграции с другими системами, например с CRM, которые могли обрабатывать эти заявки автоматически. Просто отключить публичный доступ могло нарушить ранее настроенную автоматизацию.
Не смотря на выявленные проблемы, агентство всё-таки решило ограничиться визуальными корректировками сайта. Срочное продвижение и потребность бизнеса в клиентах, которые резко сократились, сделали обновление платформы невозможным — работы по обновлению требовали времени. Часть функционала сайта не работала из-за устаревания модулей. Вопрос по исправлению доступа для ролей так и остался без внимания, исполнитель не захотел рисковать потерять клиента, а заказчику необходимо было быстро запустить рекламу.
Случай 2: Потерянный контроль над сайтом
Ко мне обратился заказчик с просьбой помочь спасти его сайт. Ранее он заказывал для себя разработку маркетплейса на WordPress у частного подрядчика. В процессе работы стоимость услуг значительно выросла. Заказчик сообщил, что полностью оплатил работу, однако подрядчик отказался передавать ему его сайт и требует дополнительную оплату. Сам же Заказчик не имеет технических знаний, чтобы проверить что происходит и предполагает, что его обманули.
Проверив хостинг заказчика я обнаружила отсутствие файлов сайта и домен, который подключен на чужой хостинг.
В ходе непростых переговоров подрядчик всё-же согласился передать мне файлы в исходном виде, оставив дальнейшее решение технических вопросов на моё усмотрение.
Я развернула сайт, исправила часть ошибок и перенесла на хостинг заказчика. В итоге сайт оказался рабочим, но требовалось наполнение и значительные доработки, так как по сути он представлял собой чистый шаблон маркетплейса.
Случай 3: Сайт и домен принадлежат агентству по условиям договора
Ко мне обратился заказчик, который хочет перенести сайт на собственный хостинг под своё управление, но не может этого сделать, так как ему отказывают в передаче ресурса. За сайт он заплатил более четверти миллиона рублей и в настоящий момент ему доступно только редактирование текста через админ-панель. При проверке я убедилась, что сайт представляет собой обычный лендинг.
Я поинтересовалась наличием заключённого договора, так как без этого невозможно обратиться к разработчику напрямую. В результате выяснилось, что по условиям договора все права на сайт и домен зарегистрированы на агентство, что лишает клиента возможности самостоятельно управлять ресурсом или переносить сайт на другой хостинг. Поддержка и обслуживание сайта осуществляется исключительно через это агентство.
Этот случай ещё раз подчеркивает важность внимательного изучения условий договора и юридических аспектов владения цифровыми активами, чтобы в будущем избежать подобных ситуаций и сохранить полный контроль над собственным сайтом.
Случай 4: Обман обернулся тройной потерей
Ко мне обратился заказчик с просьбой создать онлайн-сервис по типу «Ярмарка мастеров». Проект мне показался интересным, к тому-же меня заверили, что именно я буду заниматься его разработкой. Вдохновившись идеей я предоставляла консультации бесплатно. Переговоры длились более двух месяцев, за это время я подготовила подробнейшее техническое задание, которое мы согласовывали по каждому пункту, предложила множество идей, провела необходимые тесты и практически собрала прототип.
Когда все детали были согласованы, меня попросили предоставить техническое задание для предварительного согласования с руководством. Поскольку работа мне не была оплачена, я отправила сокращённую версию ТЗ и предупредила о том, что моя работа за составление ТЗ должна быть оплачена и тогда я отправлю полную версию. Но после этого заказчик пропал со связи.
После долгого перерыва он связался со мной с претензией: что сайт, якобы созданный по моему ТЗ, не работает, несмотря на то, что разработчику сайта заплатили вдвое больше плановой суммы. Попросил меня провести аудит сайта, чтобы выяснить, в чём проблема. Меня удивила такая наглость, но я согласилась проверить. В итоге оказалось, что сайт сделан на другой платформе и с серьёзными отклонениями от оригинального проекта, так-как это мог и видел новый разработчик сайта, т.е. на его усмотрение - сайт нуждается в переделке.
Четкая документация, соблюдение правил информационной безопасности и профессиональный подход к работе позволяют защищать бизнес от внешних угроз и внутренних рисков. Эти меры важны для сохранения целостности данных, доверия клиентов и стабильности деятельности компании.