Все учётные записи, домены и подписки проекта регистрируются на юридическое лицо заказчика до первой строки кода, а подрядчик получает именной доступ с нужной ролью. Это одно правило закрывает почти весь класс проблем с плохим расставанием и стоит на старте четыре часа и около 12 000 ₽ — против 258 000 ₽, в которые обходится возврат контроля по трём типовым сценариям привязки.
Нарушается правило почти всегда без злого умысла. Подрядчик берёт домен на себя, «чтобы не заводить вам аккаунт у регистратора», разворачивает сервер в своём облаке, «потому что там уже настроено», и создаёт бота под своим личным номером, «чтобы быстрее запустить». Каждое из этих решений экономит полчаса на старте и создаёт зависимость, которая обнаруживается в самый неудобный момент.
Ниже — двенадцать позиций с указанием владельца и того, что именно получает подрядчик, три модели доступа в панелях управления, расчёт цены возврата контроля, порядок переоформления, если всё уже оформлено не на вас, и та единственная строка в договоре, отсутствие которой само по себе является сигналом.
Двенадцать позиций: кто владелец и что получает подрядчик
Таблица заполняется до старта работ и хранится вместе с договором. Третья колонка важнее первых двух: она задаёт объём прав подрядчика, а значит, и то, что вы теряете в случае конфликта.
| Позиция | На кого оформляется | Что получает подрядчик |
|---|---|---|
| 1. Доменное имя | Юрлицо заказчика у регистратора, контакт администратора — сотрудник заказчика | Доступ к управлению DNS-записями, без права смены администратора |
| 2. Хостинг и сервер | Договор с провайдером на юрлицо заказчика, оплата с его счёта | Учётная запись с правами администратора на сервере, именная |
| 3. Репозиторий с исходным кодом | Организация или учётная запись компании заказчика | Именное приглашение с правами на запись в рабочие ветки |
| 4. База данных | Развёрнута на сервере заказчика, резервные копии — в его хранилище | Учётная запись приложения и отдельная именная для разработки |
| 5. Почтовый домен и рассылки | Юрлицо заказчика, записи подтверждения домена — в его DNS | Техническая учётная запись для отправки писем из системы |
| 6. Платёжные и SMS-сервисы | Только юрлицо заказчика: договор, реквизиты, подписант | Тестовый ключ и доступ к журналу операций без права вывода средств |
| 7. Ключи API учётных систем | Создаются администратором заказчика в его системе | Отдельный ключ с правами строго под задачу и своим сроком |
| 8. Веб-аналитика и счётчики | Аккаунт компании заказчика | Гостевой доступ на просмотр и настройку целей |
| 9. Панель мессенджер-ботов | Корпоративный номер или аккаунт компании, а не личный телефон разработчика | Токен бота и доступ к настройкам в рамках проекта |
| 10. Облачное хранилище файлов | Корпоративный аккаунт заказчика | Папка проекта с правами на запись, без прав на корень |
| 11. Лицензии и подписки на компоненты | Юрлицо заказчика, счета на его реквизиты | Доступ к загрузке дистрибутивов и обновлений |
| 12. Сертификаты: TLS, электронная подпись | Заказчик; ключ электронной подписи не передаётся никому | Сертификат TLS устанавливается на сервер, закрытый ключ остаётся у заказчика |
Платёжные сервисы и электронная подпись оформляются только на заказчика и никогда не передаются подрядчику даже временно: за операции по ним отвечает владелец юрлица, а не тот, кто фактически нажал кнопку. Просьба «дайте нам доступ к кассе, так быстрее настроим» не решается доверием — она решается тестовой средой платёжного сервиса, которая есть у всех крупных провайдеров.
Три модели доступа: как это выглядит в панелях
Технически правило «владелец — заказчик, подрядчик — роль» реализуется по-разному, и от модели зависит, насколько быстро вы сможете отозвать доступ.
- Модель ролей и приглашений. Панель различает владельца, администраторов и приглашённых участников. Подрядчик приглашается по своему адресу и получает роль; отзыв — одно действие в интерфейсе. Так устроено большинство репозиториев, облачных хранилищ, аналитики и хостинг-панелей. Это целевое состояние для всех двенадцати позиций.
- Модель одного аккаунта. Ролей нет, вход один. Встречается у небольших сервисов и старых панелей. Здесь владельцем всё равно остаётся заказчик, а подрядчику пароль выдаётся через менеджер паролей — с возможностью сменить его в любой момент без потери самого аккаунта.
- Модель привязки к личности. Аккаунт неразрывно связан с конкретным человеком: личным телефоном, личной почтой, подтверждённым профилем. Это самый опасный случай, и именно сюда попадают мессенджер-боты и часть сервисов рассылок. Единственный рабочий приём — заводить такие аккаунты на корпоративный номер и корпоративную почту, к которым доступ есть у компании, а не у сотрудника или подрядчика.
Проверка модели занимает пять минут и делается до того, как сервис вообще заведён: откройте раздел настроек и посмотрите, есть ли в нём управление участниками. Если его нет — сервис относится ко второй или третьей модели, и заводить его должен сотрудник компании, а не исполнитель.
Три сценария привязки и цена возврата контроля
Считаем три самых частых нарушения правила на модельной компании: небольшая система для отдела продаж, пять сотрудников работают в ней ежедневно. Расставание недружественное — подрядчик не помогает, но и не мешает. Технические работы берём по 2 500 ₽/час — нижняя граница рыночной вилки инженера; час простоя сотрудника — по полной ставке 700 ₽.
Первая строка взята из отдельного разбора: как раскладываются 124 000 ₽ на юриста, перенос почтового домена, перевыпуск ключей и два дня ручной обработки заявок, мы показывали в статье про передачу доступов при завершении проекта. Там же — формулировки, которыми возврат доступов привязывается к подписанию акта финального этапа.
Сравнение двух вертикальных столбцов сильно разной высоты. Левый низкий столбец «Правильно на старте — 12 000 ₽» с подписью «4 часа, все двенадцать позиций». Правый высокий столбец «Возврат контроля — 258 000 ₽» из трёх сегментов с подписями: «Домен и почта — 124 000 ₽», «Сервер в чужом облаке — 88 000 ₽», «Бот на личном аккаунте — 46 000 ₽». Между столбцами крупная подпись «×21». Внизу пометка «расчёт на компании, где в системе работают пять сотрудников». Чертёжный стиль, подписи по-русски.
Если всё уже оформлено на подрядчика
Ситуация обычная и не безнадёжная. Позиции делятся на две группы: те, которые вы можете вернуть сами, и те, где без участия исполнителя не обойтись. Начинать надо с первой группы, потому что она закрывается за один день и сразу снижает зависимость.
| Позиция | Можно ли без подрядчика | Что делать |
|---|---|---|
| Сервер и хостинг | Да, если договор с провайдером на вас | Сменить пароли, отозвать ключи доступа, проверить список администраторов |
| Репозиторий | Да, если организация ваша | Забрать полную копию с историей, удалить лишних участников |
| Ключи API учётных систем | Да | Перевыпустить в своей системе, выдать новые с ограниченным сроком |
| Веб-аналитика | Да, если аккаунт ваш | Отозвать гостевые доступы, проверить, кто получает отчёты |
| Доменное имя | Нет | Переоформление у регистратора с участием текущего администратора и документами юрлица |
| Платёжные и SMS-сервисы | Нет | Заводить заново на своё юрлицо: перенос договора обычно невозможен |
| Панель мессенджер-ботов | Нет, если аккаунт личный | Создавать бота заново на корпоративный номер, переносить сценарии, уведомлять клиентов |
| Лицензии и подписки | Нет | Проверить условия переоформления у вендора; часть лицензий именные и не переносятся |
Порядок действий такой: сначала опись — что и на кого оформлено на самом деле, а не по договорённости. Потом первая группа за один день. Потом письменный запрос на переоформление второй группы, пока отношения рабочие. Просить об этом после конфликта дороже и дольше: юридически принудить к переоформлению домена сложно, а фактически это может занять месяцы. Если проект в этот момент ещё и не закончен, разбор состояния лучше делать вместе с описью — порядок мы описали в материале про передачу незавершённого проекта.
Разделение секретов: где живут ключи и пароли
Вторая половина вопроса — не кто владеет, а как передаётся. Пароль, отправленный в переписку мессенджера, остаётся там навсегда: в истории, в резервных копиях, на устройствах всех участников чата, включая уволившихся. Отозвать его нельзя, можно только сменить — и надеяться, что вспомнили про все места, где он использовался.
- Корпоративный менеджер паролей на компанию. Один на всю организацию, с разделением по проектам. Секрет выдаётся ссылкой с ограниченным сроком жизни или общей папкой, доступ к которой снимается одним действием. Стоит это обычно меньше, чем один час работы инженера в месяц.
- Именные доступы вместо общих. У каждого человека со стороны подрядчика — свой вход. Иначе при уходе одного разработчика приходится менять пароли всей команды, а в журнале системы невозможно понять, кто что сделал.
- Разные ключи для разных сред. Тестовый контур не должен ходить в боевые сервисы теми же ключами. Это не паранойя: большинство утечек ключей происходит из тестовых конфигураций, которые никто не считает чувствительными.
- Срок жизни у каждого ключа. Ключ API, выданный подрядчику, имеет дату окончания, совпадающую с плановым концом этапа. Продление — сознательное действие, а не отсутствие действия.
- Журнал выданного. Простая таблица: что выдано, кому, когда, до какой даты, отозвано ли. Она же становится основой для отзыва доступов при завершении проекта, и её отсутствие — самая частая причина забытых учётных записей.
Карта связей. В центре крупный узел «Юрлицо заказчика — владелец». Вокруг него по кругу двенадцать узлов с подписями: домен, хостинг и сервер, репозиторий, база данных, почтовый домен, платёжные и SMS-сервисы, ключи API учётных систем, аналитика, панель мессенджер-ботов, облачное хранилище, лицензии, сертификаты. Все двенадцать соединены с центром сплошными линиями «владение». Сбоку отдельный узел «Подрядчик», от него к части узлов идут тонкие пунктирные линии с подписями «именная роль, срок до конца этапа». К узлам «платёжные и SMS-сервисы» и «сертификаты» пунктир не идёт — рядом пометка «доступ не выдаётся». Чертёжный стиль, подписи по-русски.
Одна строка в договоре и почему её отсутствие — сигнал
В договор достаточно внести одну формулировку: все учётные записи, доменные имена, лицензии и подписки, необходимые для работы результата, регистрируются на заказчика; передача прав администрирования и отзыв доступов исполнителя входят в состав приёмки соответствующего этапа. Дальше эта строка раскрывается приложением — тем самым перечнем из двенадцати позиций.
Возражения на эту строку бывают двух видов. Первое — техническое: «у нас всё настроено в своей инфраструктуре, отдельно вам будет дороже». Оно честное, его можно обсуждать: иногда действительно дешевле разместиться у исполнителя, и тогда в договоре фиксируется порядок и срок переноса, а также обязанность отдать образ сервера по запросу. Второе возражение — принципиальное: «мы всегда работаем так, вам не надо в это вникать». Это уже не аргумент, а описание бизнес-модели, в которой ваша зависимость является частью удержания клиента.
- Отказ регистрировать домен и сервер на заказчика без объяснения технической причины. Проверяется одним вопросом: «что мешает оформить договор с провайдером на нас и выдать вам администратора?».
- Предложение хранить ключи и пароли в переписке и нежелание пользоваться менеджером паролей. Мелочь, которая показывает общий уровень работы с доступами.
- Отказ включить в договор строку про регистрацию на заказчика при готовности обсуждать всё остальное. Значимость этой строки для исполнителя обратно пропорциональна её значимости для проекта.
- Просьба дать доступ к платёжному сервису или электронной подписи вместо работы в тестовой среде. Здесь исключений нет.
- Отсутствие ответа на вопрос, что происходит с доступами при завершении работ. Нормальный ответ — «отзываются по акту этапа, перечень в приложении»; ненормальный — «разберёмся по ходу».
Любой из пяти пунктов — достаточное основание не подписывать договор, и применять их стоит ко всем исполнителям одинаково. Остальные разделы, которые проверяются в договоре на разработку, собраны в отдельном разборе про то, что должно быть в договоре; а какие материалы вообще стоит показывать исполнителю до подписания, мы разобрали в статье про передачу данных до договора.
Зависимость от подрядчика создаётся не кодом, а строкой «владелец» в чужой панели управления. Она бесплатна на старте и стоит сотен тысяч потом.
