Развод сооснователей: делим доступы, домены и серверы без взаимного шантажа

MAATRIX

Двое сооснователей решили расстаться — и выясняется, что домен зарегистрирован на личный email одного из них, сервер оплачивается с личной карты другого, а пароль от панели хостинга знают оба и последний год никто его не менял. Пока отношения были рабочими, это никого не беспокоило: общий доступ — это же удобно. В момент расставания та же самая общая инфраструктура превращается в риск одностороннего вмешательства — и чем дольше решение о разделе откладывается, тем выше шанс, что кто-то из двоих успеет что-то поменять первым. Ниже — сугубо техническая сторона вопроса: что с инфраструктурой нужно сделать сразу после решения расстаться, независимо от того, как долго будет решаться вопрос долей и денег.

Важная оговорка: это не про раздел бизнеса

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

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

Домен: кто на самом деле его контролирует

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

Первый шаг — выяснить факты, а не полагаться на память:

# кто в WHOIS указан регистрантом и админ-контактом
whois vashdomen.ru

# кто хостит DNS-зону прямо сейчас
dig NS vashdomen.ru +short

# у кого какой email привязан к аккаунту регистратора — смотрите в личном кабинете

Дальше вопрос не технический, а организационный: кто из двоих остаётся владельцем домена. Если проект продолжает работать под одним из партнёров, логично, что домен остаётся у него — но это должно быть явным решением, а не фактом, который просто «так сложилось». Если домен зарегистрирован на личный email того, кто из проекта уходит, стоит сразу договориться о переносе регистрации: либо смена контактных данных регистранта на нового владельца прямо у текущего регистратора, либо перенос к другому регистратору по EPP/auth-коду с обновлением контактов уже там. Механика самого переноса и типичные грабли (блокировка Registrar Lock, 60-дневное ограничение после предыдущего переноса, отключение DNSSEC перед переносом) разобраны в статье про перенос домена к другому регистратору — процедура та же, независимо от того, меняете вы регистратора из-за цены или из-за развода партнёров.

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

Серверы и хостинг: кто платит и у кого остаётся админ-доступ

Второй уязвимый узел — сама инфраструктура: VPS, выделенные серверы, панели управления облаком. Частая ситуация для проекта на ранней стадии — сервер арендован на личную карту одного из сооснователей, потому что так было проще оформить в момент запуска, а переоформление на компанию отложили «на потом» (если у вас в проекте ровно эта стадия, отдельно разобрано в статье когда пора переоформлять сервер с личной карты на компанию).

При разводе это создаёт конкретный практический риск: тот, с чьей карты идёт оплата, физически может в любой момент попросить провайдера удалить сервер или просто перестать платить — и через грейс-период сервер уйдёт в бэкап-архив или будет снесён провайдером за неуплату. С другой стороны, тот, у кого остался root-доступ, может независимо от того, кто платит, что угодно поменять на самом сервере.

Разберите два вопроса отдельно, потому что это разные оси контроля:

• Кто платит. Если сервер продолжает использоваться, платёжный метод должен быть переоформлен на того, кто реально продолжает вести проект — с личной карты уходящего партнёра на карту оставшегося или, лучше, сразу на реквизиты компании, если она уже есть. Большинство провайдеров меняют платёжный метод в личном кабинете за несколько минут, без пересоздания сервера.
• У кого административный доступ. Это отдельно от оплаты. Тот, кто перестаёт быть причастен к проекту, должен потерять доступ к панели хостинга/облака и к самому серверу — независимо от того, кто платит. Смена пароля от панели провайдера, отзыв API-токенов и смена SSH-доступа на сервере — три разных действия, и нужны все три.

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

Общие пароли и доступы: с этого момента это риск, а не удобство

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

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

• Пароль от панели хостинга/облака — смените сразу после самой панели провайдера, включите 2FA, если ещё не было.
• Root-пароль и SSH-ключи на сервере — если оба когда-либо заходили на сервер напрямую, считайте, что оба знают достаточно, чтобы вернуться. Перевыпустите authorized_keys с нуля, оставив только ключи тех, кто реально должен иметь доступ дальше.
• Доступ к DNS-зоне — отдельно от регистратора домена, если DNS вынесен на Cloudflare или похожий сервис: смените пароль аккаунта и отзовите API-токены, которые могли быть выданы для автоматизации.
• Платёжные системы, привязанные к проекту — доступ к личному кабинету платёжного провайдера, если через него шли платежи клиентов. Здесь речь только о технической стороне: кто может входить в кабинет и видеть/менять настройки, а не о финансовом разделе выручки — это вопрос к юристу и бухгалтеру.
• Общие облачные хранилища и репозитории с секретами — .env-файлы, файлы с ключами API, менеджер паролей команды (Vaultwarden, 1Password и подобные), если он был общим.

Ключевой момент по срокам: смена доступов должна произойти сразу после того, как решение о расставании принято обеими сторонами — не после того, как юрист оформит раздел долей или подпишет соглашение. Юридическое оформление может занять недели или месяцы, а риск одностороннего вмешательства в инфраструктуру начинается в тот момент, когда решение принято и кто-то из двоих об этом узнал. Ждать бумажной формализации, чтобы сменить пароли, — это оставлять открытой дверь ровно тогда, когда мотив её использовать максимален.

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

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

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

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

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

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

# кто вообще может зайти
getent passwd > passwd.txt
find / -name authorized_keys 2>/dev/null -exec cat {} \; > all_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

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

Кто остаётся администратором — и как зафиксировать решение

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

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

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

Раздел инфраструктуры проекта, [дата]

- Домен project.io — остаётся у [Имя А], регистратор Х
- Сервер prod (IP xxx.xxx.xxx.xxx) — остаётся у [Имя А]
- GitHub-организация — остаётся у [Имя А], [Имя Б] удалён из участников
- Домен project-tools.io — переходит [Имя Б] для нового проекта
- Аккаунт платёжной системы — остаётся у [Имя А], доступ [Имя Б] отозван [дата]
- Пароли всех систем выше сменены обеими сторонами синхронно [дата]

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

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