Сайт есть, а контроля нет: 10 пунктов, которые бизнесу нужно проверить прямо сейчас

Корпоративный сайт может работать годами, но в критический момент выясняется, что бизнес не контролирует ни домен, ни хостинг, ни резервные копии. Чтобы снизить этот риск, достаточно провести аудит основных цифровых активов: проверить владельцев аккаунтов, доступы, платежи, бэкапы и возможность восстановить проект без участия текущего подрядчика.

Проблемы обычно обнаруживаются в самый неподходящий момент: при смене разработчика, увольнении сотрудника, переезде на другой хостинг, атаке на сайт или необходимости срочно восстановить данные.

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

Сайт формально принадлежит бизнесу, но фактически управлять им бизнес не может.

Контроль должен распространяться не только на административную панель сайта, но и на всю связанную инфраструктуру: домен, хостинг или VDS, базу данных, корпоративную почту, подключенные сервисы и резервные копии.

Разберем, что именно необходимо проверить, чтобы корпоративный сайт не зависел от одного сотрудника, подрядчика или утерянного пароля.

Сайт — это не один объект

Для руководителя или маркетолога сайт часто выглядит как единая система. В действительности он состоит из нескольких независимых элементов:

1. доменного имени;
2. хостинга или виртуального сервера;
3. системы управления сайтом;
4. базы данных;
5. корпоративной почты;
6. SSL-сертификата;
7. DNS-записей;
8. сервисов аналитики, рекламы, CRM и телефонии;
9. репозитория с исходным кодом;
10. резервных копий.

У каждого элемента могут быть отдельные учетные записи, владельцы, подрядчики и сроки оплаты.

Поэтому доступ к административной панели сайта еще не означает, что компания действительно контролирует весь проект. Можно редактировать тексты и изображения, но не иметь возможности продлить домен, перенести сайт или восстановить базу данных.

Главный принцип: компания должна контролировать ключевые аккаунты и данные, даже если техническое обслуживание полностью передано подрядчику.

1. Проверьте, на кого зарегистрирован домен

Домен — один из главных цифровых активов компании. По этому адресу клиенты находят сайт, переходят из поисковых систем и отправляют письма на корпоративную почту.

При этом домены нередко регистрируются:

1. на сотрудника, который запускал сайт;
2. на владельца веб-студии;
3. на технического специалиста;
4. на личную почту директора;
5. на аккаунт, данные от которого никто не помнит.

Пока домен оплачен и сайт работает, проблема остается незаметной. Но при конфликте с подрядчиком, увольнении сотрудника или утрате доступа компания может не суметь продлить домен, изменить DNS-записи или перенести его к другому регистратору.

Что проверить

1. Проверьте, кто указан администратором домена.
2. Убедитесь, что у компании есть доступ к аккаунту регистратора.
3. Зафиксируйте адрес электронной почты, привязанный к аккаунту.
4. Включите двухфакторную аутентификацию.
5. Проверьте дату окончания регистрации.
6. Настройте автоматическое продление или напоминание об оплате.
7. Убедитесь, что уведомления получает действующий сотрудник.

Даже временная потеря домена может привести к остановке сайта и корпоративной почты.

Вывод: домен должен быть оформлен на компанию или ее владельца, а доступ к аккаунту регистратора не должен зависеть от одного сотрудника или подрядчика.

2. Убедитесь, что хостинг оформлен на компанию

Следующий уровень — хостинг или сервер, на котором размещены сайт, база данных и связанные сервисы.

Распространенная ситуация: подрядчик размещает проекты нескольких клиентов в своем аккаунте. Бизнес получает работающий сайт, но не имеет отдельного доступа к инфраструктуре.

Такой вариант может работать годами. Однако при прекращении сотрудничества возникают вопросы:

1. как перенести сайт;
2. где находится база данных;
3. кто оплачивает сервер;
4. можно ли получить актуальную резервную копию;
5. какие еще проекты размещены на той же площадке;
6. кому принадлежит аккаунт у хостинг-провайдера.

Иногда компания даже не знает, у какого провайдера находится ее сайт.

Более безопасная схема — оформлять хостинг или сервер на собственный аккаунт компании, а подрядчику предоставлять отдельный доступ для работы. Например, AdminVPS работает по модели «Всё включено»: техническое администрирование можно передать специалистам провайдера, при этом сама услуга и управление аккаунтом остаются под контролем клиента.

Что должно быть у бизнеса

1. Проверьте адрес панели управления.
2. Зафиксируйте логин владельца аккаунта.
3. Убедитесь, что компания контролирует привязанную почту.
4. Проверьте название тарифа и параметры сервера.
5. Зафиксируйте дату следующей оплаты.
6. Сохраните контакты технической поддержки.
7. Уточните порядок переноса сайта и получения резервной копии.
8. Проверьте данные для подключения к серверу или панели хостинга.

Передавать подрядчику единственную учетную запись владельца необязательно. Лучше создавать отдельные учетные записи и ограничивать права в зависимости от задач.

Вывод: хостинг должен быть оформлен на компанию, а подрядчик должен получать рабочий доступ, но не единоличный контроль над инфраструктурой.

3. Проверьте доступы к сайту и серверу

Один общий логин вида admin для всех сотрудников и подрядчиков — удобное, но рискованное решение.

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

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

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

Какие доступы стоит проверить

1. Проверьте административную панель CMS.
2. Убедитесь, что есть доступ к панели хостинга.
3. Зафиксируйте данные FTP или SFTP.
4. Проверьте SSH-доступ к серверу.
5. Убедитесь, что есть доступ к базе данных.
6. Проверьте аккаунт регистратора домена.
7. Зафиксируйте доступы к корпоративной почте.
8. Проверьте системы аналитики и вебмастеров.
9. Убедитесь, что компания контролирует рекламные кабинеты.
10. Проверьте CRM, телефонию и сервисы обратного звонка.
11. Зафиксируйте доступ к CDN и системе защиты сайта.
12. Проверьте репозитории с исходным кодом.

Отдельно необходимо посмотреть, какие права остались у бывших сотрудников и подрядчиков. Неактуальные учетные записи следует отключить.

Вывод: у каждого пользователя должна быть отдельная учетная запись с минимально необходимыми правами.

4. Разберитесь, где хранятся пароли

Пароли часто находятся в личных чатах, текстовых файлах, таблицах без защиты или заметках одного сотрудника.

Это создает сразу несколько рисков:

1. данные могут потеряться;
2. пароль может попасть третьим лицам;
3. невозможно контролировать, кто им пользовался;
4. после увольнения сотрудника часть доступов исчезает вместе с ним;
5. один скомпрометированный пароль открывает доступ сразу к нескольким системам.

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

Двухфакторную аутентификацию желательно включить как минимум для:

1. регистратора домена;
2. хостинга;
3. корпоративной почты;
4. CMS;
5. облачных сервисов;
6. рекламных кабинетов;
7. систем аналитики;
8. репозиториев с кодом.

Коды восстановления тоже должны храниться централизованно, а не только на телефоне одного сотрудника.

Вывод: пароли и резервные коды должны храниться в корпоративной системе, доступ к которой можно контролировать и передавать.

5. Уточните, существуют ли резервные копии

Фраза «у нас настроены бэкапы» сама по себе ничего не гарантирует.

Важно понимать:

1. что именно копируется;
2. как часто создаются копии;
3. сколько времени они хранятся;
4. где находятся;
5. кто имеет к ним доступ;
6. можно ли восстановить из них сайт;
7. когда восстановление проверялось в последний раз.

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

Другая распространенная ошибка — хранить резервную копию на том же сервере, где находится сайт. Если сервер будет поврежден, зашифрован или недоступен, вместе с основными данными можно потерять и бэкап.

Для важных проектов лучше использовать отдельный сервис резервного копирования, чтобы копии хранились независимо от основного сайта или сервера. В AdminVPS резервное копирование организовано как отдельная услуга: это снижает риск одновременной потери основных данных и их копий.

Что должно входить в резервную копию

1. Файлы сайта.
2. База данных.
3. Конфигурация веб-сервера.
4. Почтовые данные, если почта размещена на том же сервере.
5. Загруженные пользователями документы и изображения.
6. Параметры интеграций.
7. Конфигурационные файлы приложения.
8. Данные, необходимые для повторного запуска проекта.

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

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

Главное правило: бэкап считается рабочим только после тестового восстановления.

Вывод: резервные копии должны создаваться регулярно, храниться отдельно от основного сервера и периодически проверяться восстановлением.

6. Проверьте, можно ли восстановить сайт без текущего подрядчика

Компания может иметь формальные доступы, но не понимать, как устроен проект.

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

Чтобы оценить реальный уровень контроля, стоит задать простой вопрос:

Сможет ли другой специалист восстановить и запустить сайт, если текущий подрядчик перестанет выходить на связь?

Для этого бизнесу могут понадобиться:

1. актуальная копия файлов и базы данных;
2. доступ к репозиторию;
3. перечень используемых технологий;
4. информация о версии CMS и модулей;
5. список интеграций;
6. инструкция по развертыванию;
7. описание фоновых задач;
8. данные о лицензиях;
9. контакты поставщиков внешних сервисов;
10. информация о нестандартных настройках.

Для небольшого корпоративного сайта документация может занимать одну страницу. Но даже такой документ существенно упрощает передачу проекта новому специалисту.

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

7. Обратите внимание на корпоративную почту

Почта на собственном домене связана с доменом и DNS-настройками. Если компания потеряет управление доменом, могут перестать работать не только сайт, но и адреса сотрудников.

Отдельный риск — регистрация критически важных сервисов на почту конкретного работника. После его увольнения восстановить доступ к хостингу, аналитике или рекламному кабинету становится сложнее.

Для ключевых аккаунтов лучше использовать функциональные адреса:

1. admin@company.ru;
2. it@company.ru;
3. billing@company.ru;
4. marketing@company.ru.

Доступ к таким ящикам должен контролироваться компанией, а не конкретным сотрудником.

Вывод: критические сервисы лучше регистрировать на корпоративные функциональные адреса, доступ к которым не исчезает после увольнения сотрудника.

8. Проверьте платежи и уведомления

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

Если уведомления приходят на неактуальную почту, компания может узнать о проблеме уже после отключения услуги.

Следует составить единый список, в котором будут указаны:

1. используемый сервис;
2. владелец аккаунта;
3. стоимость;
4. дата продления;
5. способ оплаты;
6. ответственный сотрудник;
7. адрес для получения уведомлений.

Особенно важно проверить автоматические платежи с личных банковских карт работников. После увольнения сотрудника карта может быть заблокирована, а услуга — неожиданно отключена.

Вывод: все платежи, сроки продления и уведомления должны быть зафиксированы в едином реестре.

9. Проверьте подключенные сервисы

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

1. CRM;
2. онлайн-оплата;
3. телефония;
4. сервисы рассылок;
5. формы обратной связи;
6. чат-боты;
7. системы аналитики;
8. рекламные пиксели;
9. облачные хранилища;
10. сервисы доставки;
11. API внешних платформ.

Часть этих интеграций может быть оформлена на подрядчика или личный аккаунт сотрудника.

Необходимо проверить, кому принадлежат учетные записи, где находятся ключи API, кто получает уведомления и что произойдет, если доступ к сервису будет потерян.

Вывод: компания должна контролировать не только сам сайт, но и внешние сервисы, без которых он не сможет полноценно работать.

10. Назначьте ответственного за цифровую инфраструктуру

Даже полный список доступов быстро устареет, если никто не отвечает за его актуальность.

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

В его задачи должны входить:

1. актуализация списка доступов;
2. контроль сроков оплаты;
3. отключение бывших сотрудников;
4. проверка резервных копий;
5. фиксация новых интеграций;
6. контроль передачи проекта между подрядчиками;
7. периодический аудит инфраструктуры.

Проверку желательно проводить не только после кадровых изменений или сбоев, а регулярно — например, один или два раза в год.

Вывод: у цифровых активов должен быть конкретный ответственный внутри компании.

Красные флаги: когда контроль уже потерян

Провести аудит необходимо как можно быстрее, если:

1. никто точно не знает, где зарегистрирован домен;
2. хостинг оформлен на подрядчика;
3. все используют один пароль;
4. резервные копии никогда не восстанавливались;
5. уведомления об оплате приходят бывшему сотруднику;
6. у компании нет доступа к базе данных;
7. исходный код находится только на компьютере разработчика;
8. корпоративная почта зависит от одного администратора;
9. нет списка подключенных сервисов;
10. при смене подрядчика сайт невозможно передать без его участия.

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

Краткий чек-лист для бизнеса

Зафиксируйте в одном документе:

1. Где зарегистрирован домен и кто владеет аккаунтом.
2. Где размещен сайт и на кого оформлен хостинг.
3. Кто имеет административные доступы.
4. Где хранятся пароли и резервные коды.
5. Как создаются и хранятся резервные копии.
6. Когда последний раз проверялось восстановление.
7. Какие сотрудники и подрядчики имеют доступ.
8. Какие сервисы подключены к сайту.
9. Когда необходимо продлить домен, сервер и лицензии.
10. Кто отвечает за инфраструктуру внутри компании.

После аудита необходимо закрыть лишние учетные записи, включить двухфакторную аутентификацию, перенести критические сервисы на корпоративные адреса и убедиться, что у компании есть актуальная резервная копия.

Контроль — это не обязанность самостоятельно администрировать сервер

Бизнесу необязательно самостоятельно настраивать сервер, обновлять CMS или разбираться в DNS. Эти задачи можно передать штатному специалисту, веб-студии или провайдеру с полным циклом управления, например AdminVPS.

Но техническую работу можно делегировать только тогда, когда компания сохраняет контроль над цифровыми активами.

Домен, хостинг, данные, резервные копии и ключевые учетные записи должны оставаться под управлением бизнеса. Подрядчики могут получать необходимые права для работы, но не должны быть единственными людьми, от которых зависит доступ к сайту.

Проверка инфраструктуры занимает значительно меньше времени и средств, чем экстренное восстановление сайта после блокировки аккаунта, конфликта с разработчиком или потери данных.

Поэтому лучший момент для аудита доступов и инфраструктуры — не после аварии, а пока сайт работает стабильно.

FAQ