Продаём проект: как передать инфраструктуру покупателю и закрыть свои риски

MAATRIX

Договорились о цене, обменялись рукопожатием (или подписали term sheet) — и тут выясняется, что «передать проект» на практике означает десяток разрозненных действий: отдать пароль от хостинга, перенести домен, добавить в GitHub-организацию, вспомнить, на чьей карте висит подписка на аналитику. Частый сценарий провала — либо продавец вываливает покупателю все пароли одним архивом ещё до того, как деньги дошли, либо тянет с передачей до последнего и через полгода после сделки продолжает получать письма от регистратора домена на свою личную почту. Ниже — практический план технической передачи: что инвентаризировать, в каком порядке выдавать доступы, как зафиксировать момент перехода ответственности и как продавцу закрыть свои риски после того, как деньги получены.

Важная оговорка: это не про оформление самой сделки

Всё, что написано дальше, — про техническую сторону: серверы, домены, репозитории, учётные записи сервисов. Это не консультация по структуре сделки, договору купли-продажи бизнеса или актива, эскроу, гарантиям продавца (representations & warranties), передаче прав на товарный знак или интеллектуальную собственность, налоговым последствиям продажи. Всё это — территория юриста, и для сделки с заметной суммой его стоит привлекать до подписания чего-либо, а не после того, как техническая передача уже случилась. Хорошая практика — синхронизировать техническую часть с юридической: полный доступ покупатель получает не раньше, чем деньги реально поступили и это подтверждено, а не «на словах договорились». Но конкретный момент, договор, эскроу-агент, форма оплаты — решает юрист вместе со сторонами сделки, а не эта статья.

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

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

Частая ошибка продавца — передавать инфраструктуру по мере того, как покупатель о ней спрашивает: «а, точно, ещё есть Redis на отдельном сервере», «забыл, домен для API отдельный». Каждый такой довесок подрывает доверие и создаёт риск, что что-то забудется насовсем — а через полгода после сделки продавцу придёт письмо о продлении домена, о котором никто не вспомнил.

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

Для самого сервера список процессов и портов удобнее не вспоминать по памяти, а снять автоматически:

mkdir -p ~/handover-$(date +%Y%m%d)
cd ~/handover-$(date +%Y%m%d)

# кто может зайти
getent passwd > passwd.txt
find / -name authorized_keys 2>/dev/null -exec cat {} \; > authorized_keys.txt

# что установлено и что слушает сеть
dpkg -l > packages.txt 2>/dev/null || rpm -qa > packages.txt
ss -tulnp > listening_ports.txt

# автозадачи и таймеры — частый источник забытых интеграций
crontab -l > root_crontab.txt 2>&1
systemctl list-timers --all > timers.txt

Подробная методика такой описи — в статье про инвентаризацию сервера: по сути это тот же реестр серверов и доступов, только собранный не для внутреннего порядка, а для передачи внешней стороне. Итоговый список стоит зафиксировать письменно (таблица в документе, а не переписка в мессенджере) и приложить к акту передачи — покупателю важно видеть цельную картину сразу, а не собирать её по кускам в процессе.

Поэтапная передача доступов: не всё и не сразу

Выдать покупателю полный root и пароли от всего в первый же день переговоров — риск для обеих сторон: сделка может сорваться на любом этапе, а отозвать уже переданный доступ технически можно, но создаёт основания для спора («вы же сами всё отдали, а теперь блокируете»). Обратная крайность — тянуть с любым доступом до последнего — тоже плохо: покупатель не может провести due diligence вслепую, по одним словам продавца.

Разумная последовательность — три этапа с разным объёмом доступа:

Этап 1. Due diligence, до подписания. Административный доступ не нужен — достаточно демонстрации экрана вместо реальных паролей, временной учётки с ролью read-only в панели хостинга или репозитории, если она есть, санитизированной выписки инвентаризации без ключей и паролей, а при необходимости — доступа к staging-окружению вместо продакшена.

Этап 2. После подписания договора, до полного закрытия сделки (до поступления оплаты или истечения эскроу-периода). Здесь уместен рабочий, но не полновластный доступ: отдельный пользователь с ограниченным sudo вместо root, доступ на чтение к репозиторию без прав владельца организации. Методика такого ограниченного доступа разобрана в статье про передачу сервера подрядчику — принцип «отдельная учётка, минимум прав, доступ по SSH-ключу, а не общий пароль» работает для покупателя так же, как для внешнего подрядчика: он ещё не полноправный владелец, но уже должен иметь возможность работать и проверять.

Этап 3. После полного закрытия сделки. Только теперь — перенос регистратора домена на нового владельца, передача владения GitHub/GitLab-организацией, полный root/админ-доступ, смена платёжного метода на реквизиты покупателя. Этот доступ уже нельзя частично отозвать без конфликта, поэтому он выдаётся в последнюю очередь, а не в первую.

Практическое правило для паролей на любом из этапов: не пересылать их текстом в почте или мессенджере. Используйте менеджер паролей с ограничением по времени (Vaultwarden, 1Password и подобные) или сервис одноразовых секретных ссылок — так доступ не осядет в истории переписки на годы вперёд.

Момент перехода ответственности: зафиксировать явно, а не оставить размытым

Самый частый источник конфликтов после сделки — не техническая ошибка, а неясность: с какого момента за инциденты и оплату отвечает покупатель, а с какого — ещё продавец. Если сайт лёг через два дня после «в целом передали доступы», кто должен был на это реагировать? Если хостинг не оплатили вовремя и сервер попал под угрозу удаления — с чьей карты должен был пройти платёж?

Фиксировать нужно не общую фразу «передача произошла», а конкретные даты и зоны ответственности по каждому пункту инвентаризации:

Ключевой нюанс — не оставлять переходный период неопределённым по срокам. Формулировка «пока идёт передача, отвечаем вместе» на практике означает, что не отвечает никто: оба считают, что реагирует другая сторона. Лучше явно прописать короткий переходный период с конкретной датой окончания, в течение которого продавец на связи для вопросов, но уже не несёт ответственности. Эта таблица не заменяет договор, но становится приложением к акту передачи и опорным документом, если через месяц кто-то не вспомнит, что именно решили.

Смена всех критичных учётных данных после передачи

После того как сделка закрыта и покупатель получил полный доступ (этап 3 выше), продавец обязан перестать иметь возможность попасть в системы проекта. Это не вопрос недоверия — это базовая гигиена, которая защищает обе стороны: продавца — от того, что его через полгода обвинят в инциденте, к которому он не имел отношения, покупателя — от того, что у бывшего владельца остаётся техническая возможность вмешаться.

Список того, что нужно сменить именно после закрытия сделки (не раньше — до этого момента продавец ещё может быть единственным, кто способен восстановить доступ, если что-то пойдёт не так):

• Пароль от панели хостинга/облака — новый пароль задаёт покупатель, старый сразу становится нерабочим.
• Root-пароль и SSH-ключи на сервере. Продавец заходил напрямую — его ключ нужно убрать полностью, а не «на всякий случай оставить закомментированным».

# на сервере, от имени нового администратора
cp /root/.ssh/authorized_keys /root/.ssh/authorized_keys.bak
# перевыпустить файл, оставив только ключи новой команды
> /root/.ssh/authorized_keys
cat new_admin_key.pub >> /root/.ssh/authorized_keys

# сгенерировать новую пару ключей для входа, если старая тоже была скомпрометирована доверием
ssh-keygen -t ed25519 -C "new-admin-$(date +%Y%m%d)"

• 2FA — если старый номер телефона или приложение-аутентификатор продавца остаётся привязанным к аккаунту хостинга, регистратора или репозитория, покупатель формально зависит от него при восстановлении доступа. Перевыпустите 2FA на реквизиты покупателя.
• Аккаунт регистратора домена — смена пароля и e-mail для входа, если аккаунт переходит покупателю целиком, либо полный перенос домена (EPP/auth-код) к регистратору покупателя, если аккаунт остаётся у продавца для других его проектов.
• DNS-провайдер (если вынесен отдельно, например Cloudflare) — новый пароль, отзыв старых API-токенов.
• Платёжные системы и биллинг — доступ в кабинет платёжного провайдера, если через него шли платежи клиентов проекта; здесь речь только о том, кто может входить и менять настройки, финансовая сторона расчётов между продавцом и покупателем — вопрос к бухгалтеру.
• Репозитории кода — передача владения организацией на GitHub/GitLab, полное удаление продавца из состава участников, если он больше не работает над проектом.
• Общие хранилища, менеджер паролей команды, .env-файлы с секретами — если продавец имел к ним доступ, все ключи и токены внутри считаются скомпрометированными для нового владельца и должны быть перевыпущены, а не просто «доступ отозван».

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

Закрываем риски продавца: чужих данных не должно оставаться в системах

Отдельная задача, которая касается уже интересов продавца, — убедиться, что после сделки в переданных системах не осталось персональных данных, привязанных лично к нему. Неосторожность здесь бьёт по бывшему владельцу спустя месяцы: домен продан, а письмо о его продлении по-прежнему приходит на личную почту продавца, потому что именно она указана как контактный email у регистратора; хостинг оплачивается автосписанием с личной карты продавца, потому что при передаче доступов поменяли пароль от панели, но не платёжный метод.

Перед тем как считать передачу завершённой, продавцу стоит пройтись по каждому сервису из инвентаризационного списка и проверить три вещи:

• Контактный/восстановительный email. У регистратора домена, в панели хостинга, в SaaS-аккаунтах — везде, где указан email для связи или восстановления доступа, он должен быть заменён на email покупателя, а не оставлен личным адресом продавца «для порядка».
• Платёжный метод. Личная карта продавца должна быть отвязана от всех подписок и автосписаний проекта — иначе через месяц-два придёт списание за то, что уже не принадлежит продавцу, либо оплата не пройдёт (карта заблокирована или перевыпущена) и сервис отключится, а виноватым по факту будет считаться продавец.
• Номер телефона для 2FA и восстановления. Тот же принцип, что и с почтой: если старый номер продавца остаётся резервным способом входа, формально он всё ещё может восстановить доступ к аккаунту покупателя через службу поддержки провайдера, даже если пароль давно сменён.

Практический способ ничего не упустить — тот же инвентаризационный список, пройденный в обратную сторону: не «что передать», а «что из моих личных данных ещё где-то привязано». Частая ловушка — обнаружить это не сразу, а через полгода-год, когда придёт письмо о продлении домена на старую почту; лучше сразу закладывать проверку контактных данных как отдельный пункт чек-листа передачи.

Последний шаг — получить от покупателя письменное подтверждение, что передача завершена и всё из инвентаризационного списка получено и проверено. Формат может быть простым: email с датой, где явно перечислено, что передано, и покупатель подтверждает получение полного и рабочего доступа. Это не заменяет договор купли-продажи, но даёт продавцу опору, если через несколько месяцев возникнет спор о том, кто отвечал за инцидент в спорный период. Если сумма сделки заметная, это подтверждение стоит оформить как приложение к договору вместе с юристом, а не оставлять только в переписке.

Частые вопросы