Передача прав и доступов на IT-проект: правила безопасной приемки кода и дизайна

Передача прав и доступов на IT-проект: правила безопасной приемки кода и дизайна

В реальной эксплуатации проблемы начинаются не там, где «не тот оттенок кнопки», а там, где заказчик вроде бы оплатил сайт, но домен всё ещё на подрядчике, репозиторий висит в личном GitHub разработчика, а макеты в Figma принадлежат дизайнеру-фрилансеру.

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

Гражданский кодекс РФ задаёт базовую рамку: исключительные права на код, базу данных, дизайн и другие результаты интеллектуальной деятельности переходят не потому, что «работы оплачены», а потому, что это прямо предусмотрено договором и подтверждено передачей результата. Акт приёмки сайта сам по себе фиксирует выполнение работ, но не всегда закрывает вопрос прав. Для IT-проекта это принципиальная разница: можно принять работу и всё равно не получить полный юридический контроль над тем, что принято.

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

Юридический фундамент: почему акт приемки не заменяет договор отчуждения прав

Объект передачи в IT-проекте редко бывает одним «сайтом». Обычно это набор самостоятельных результатов и технических активов:

• исходный код — программа для ЭВМ в смысле статьи 1261 ГК РФ;
• база данных — если есть структурированная совокупность материалов и отдельная ценность в её подборе или организации;
• дизайн-макеты, иконки, иллюстрации, UI-компоненты — произведения графического дизайна;
• тексты, фотографии, видео, схемы, если они создавались специально для проекта;
• настройки инфраструктуры, конфигурации, скрипты развёртывания, документация;
• доменное имя и учётные записи в сервисах — не объекты авторского права, но критичные точки контроля.

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

Чтобы не спорить о смысле фразы «передаёт результат работ», в договоре нужно разделять три слоя.

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

Второй — состав результата: какие именно файлы, репозитории, макеты, базы, документы и настройки должны быть переданы. Не «сайт», а, например, исходный код фронтенда и бэкенда, дамп базы, инструкция развёртывания, Figma-файлы, экспорт SVG-иконок, список внешних библиотек, конфиги CI/CD без секретов.

Третий — режим прав: отчуждение исключительного права или лицензия. По статье 1234 ГК РФ исключительное право может быть отчуждено полностью. По статье 1235 ГК РФ можно предоставить лицензию — то есть право использовать результат в оговорённых пределах. Для заказчика, который хочет свободно развивать продукт, менять подрядчиков, продавать бизнес или передавать проект инвестору, чаще нужен именно понятный переход исключительных прав либо широкая лицензия без ловушек по сроку, территории и способам использования.

Со статьями 1296 и 1297 ГК РФ важно не упрощать. Они не говорят универсально обо всех «произведениях по заказу» и не заменяют договор.

Статья 1296 регулирует программы для ЭВМ и базы данных, созданные по договору, предметом которого было их создание. Общее правило там такое: исключительное право принадлежит заказчику, если договором не предусмотрено иное. То есть для заказной разработки программы или базы закон действительно поддерживает позицию заказчика, но только в пределах конкретного режима и конкретного объекта.

Статья 1297 — другой случай. Она касается программ для ЭВМ и баз данных, созданных при выполнении договора, который прямо не предусматривал их создание. В такой ситуации исключительное право по общему правилу принадлежит подрядчику, если стороны не договорились иначе, а заказчик получает право использовать программу или базу для целей соответствующего договора. Это не правило о служебных произведениях: служебные произведения регулируются другими нормами, в частности статьёй 1295 ГК РФ.

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

Типовые ошибки при оформлении выглядят так:

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

Безопасная приёмка требует не горы бумаги, а связанного комплекта документов:

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

2. Акт приёмки работ: подтверждает, что разработка выполнена и результат предъявлен заказчику.

3. Акт приёма-передачи исключительных прав или отдельный раздел в акте: перечисляет код, базы, макеты, графику, документацию и иные объекты.

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

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

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

Перенос инфраструктуры: смена администратора домена и работа с регистраторами

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

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

Обычный порядок выглядит так:

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

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

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

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

5. Подтвердить принятие домена новым администратором в личном кабинете.

6. После смены администратора обновить контакты, включить продление, проверить DNS и доступы к почте.

Здесь нет универсальной кнопки, одинаковой для всех зон и всех регистраторов. В зоне.RU и.РФ действуют свои регламентные ограничения, в международных зонах — свои процедуры трансфера и смены registrant. Поэтому безопаснее не переносить домен «по памяти», а заранее открыть правила конкретного регистратора и пройти их как юридическую процедуру, а не как техническую настройку.

Критичные условия перед передачей домена:

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

Отдельная боль — почта на домене. У сайта может быть простой A-запись на сервер, а у почты — MX, SPF, DKIM, DMARC, записи для рассылочного сервиса и CRM. Если сменить DNS неаккуратно, сайт переживёт миграцию, а почта продаж ляжет. Поэтому перед финальным расчётом нужно выгрузить текущую DNS-зону и сверить её с фактическими сервисами: сайт, почта, CDN, аналитика, верификации, платёжные шлюзы, рекламные кабинеты.

Техническая миграция репозиториев: нюансы передачи прав в GitHub

Репозиторий — это не просто архив с кодом. В нём живёт история изменений, релизные теги, pull request’ы, issues, настройки CI/CD, секреты, права команд, webhooks, GitHub Apps, иногда — пакеты и GitHub Pages. Передать ZIP-архив с последней версией можно за пять минут, но это не безопасная приемка IT проекта. Без истории и настроек новая команда получает слепок без контекста.

Правильнее передавать не «папку с кодом», а владение репозиторием или организацией. Если подрядчик вёл разработку в своём личном аккаунте, лучший вариант — создать организацию заказчика и перенести репозиторий туда. Тогда дальнейшие права выдаются не людям «на доверии», а через роли, команды и политики доступа.

Алгоритм передачи репозитория в GitHub в общем виде такой:

1. Текущий владелец открывает настройки репозитория.

2. В разделе управления репозиторием выбирает передачу ownership.

3. Указывает нового владельца — пользователя или организацию.

4. Новый владелец принимает приглашение на передачу.

5. После перехода проверяются права, интеграции и настройки безопасности.

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

Перед запуском передачи стоит проверить:

• нет ли приватных форков и зависимостей, которые помешают переносу;
• не занято ли имя репозитория у нового владельца;
• какие GitHub Apps и OAuth-приложения подключены к репозиторию;
• какие webhooks отправляют события во внешние системы;
• используются ли GitHub Actions и какие секреты в них заведены;
• опубликован ли сайт через GitHub Pages и привязан ли кастомный домен;
• есть ли packages, container registry или артефакты сборки;
• кто состоит в collaborators и какие права у команд.

После передачи новый владелец не должен просто радоваться зелёной галочке owner. Нужно провести короткую, но жёсткую ревизию:

• удалить бывших подрядчиков из collaborators, если им не нужен дальнейший доступ;
• заменить deploy keys, SSH-ключи, personal access tokens и токены CI/CD;
• пересоздать Secrets в GitHub Actions, особенно если они дают доступ к продакшену;
• проверить branch protection rules, обязательные review, запрет force push в главные ветки;
• обновить remote origin у новой команды;
• просканировать историю на случайно закоммиченные ключи, пароли и токены;
• сверить README, инструкции развёртывания и переменные окружения.

Секреты — отдельная тема. Если пароль базы данных однажды попал в Git, простое удаление строки в новом коммите не делает его безопасным: значение остаётся в истории. В таком случае пароль нужно считать скомпрометированным и перевыпустить. То же касается API-ключей платёжных систем, SMTP-паролей, токенов CDN, ключей облачных хранилищ и webhook-секретов.

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

Передача дизайн-макетов: как корректно сменить владельца в Figma

Figma для заказчика часто выглядит как «ссылка на макет». Для дизайнера — как рабочее пространство с файлами, библиотеками, компонентами, шрифтами, комментариями, историями версий и правами команды. Если передача дизайн-макетов сводится к «дали view-доступ», заказчик не получил актив. Он получил возможность посмотреть на актив в чужом кабинете.

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

Общий порядок передачи в Figma:

1. Определить, где лежат макеты: Drafts личного аккаунта, проект команды, организация, отдельный team space.

2. Создать или подготовить рабочее пространство заказчика.

3. Передать ownership файлов или переместить их в команду заказчика способом, который поддерживает текущий тариф и права владельца.

4. Проверить, что заказчик стал владельцем или администратором нужного пространства.

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

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

Что нужно принять вместе с макетами:

• исходные Figma-файлы всех ключевых экранов;
• дизайн-систему: компоненты, стили, токены, состояния, варианты;
• библиотеки и UI-kit, если они создавались в рамках проекта;
• экспорт иконок и иллюстраций в рабочих форматах;
• прототипы пользовательских сценариев;
• комментарии, если в них есть решения по логике продукта;
• список используемых шрифтов и лицензий;
• список сторонних ассетов, шаблонов и плагинов, важных для работы.

С комментариями нужна аккуратность. В них могут быть продуктовые решения, замечания юристов, обсуждения персональных данных, внутренние суммы, имена клиентов. Перед передачей подрядчик и заказчик должны решить, что оставить как часть истории проекта, а что удалить или вынести в закрытую документацию. «Всё в комментариях» удобно до первого аудита.

Для страховки стоит сделать независимый экспорт: PDF для общего просмотра, PNG или JPG для ключевых экранов, SVG для иконок и графики, если это допустимо лицензией. Такой экспорт не заменяет ownership, но помогает пережить спор, сбой аккаунта или внезапное отключение доступа. Особенно если проект передаётся между несколькими командами и часть людей уже покидает процесс.

Безопасная ревизия: аудит доступов и защита данных перед финальным расчетом

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

Доступ, который нельзя отозвать у старой команды, — это не переданный доступ. Это зависимость, временно замаскированная под сотрудничество.

Ревизия начинается с карты доступов. Не с просьбы «пришлите все пароли», а с перечня систем, где проект живёт:

• регистратор домена;
• DNS-хостинг;
• основной хостинг или облачный провайдер;
• серверы, контейнеры, панели управления;
• GitHub, GitLab или другая Git-платформа;
• Figma и графические хранилища;
• CMS и административные панели;
• база данных;
• файловое хранилище;
• CDN;
• почтовый сервис;
• платёжные системы;
• CRM и формы заявок;
• аналитика и пиксели рекламы;
• мониторинг ошибок и логов;
• рассылочные сервисы;
• карты, SMS, push, авторизация через внешних провайдеров.

По каждой системе нужно понять три вещи: кто владелец, кто администратор, кто имеет технический доступ. Это разные роли. В платёжной системе владельцем договора может быть заказчик, но API-ключи лежат у подрядчика. В облаке заказчик может оплачивать счёт, но root-пользователь создан на почту разработчика. В Figma заказчик может быть editor, но owner — дизайнер.

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

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

Потом начинается отзыв старых доступов. FTP-аккаунты, SSH-ключи, пользователи панели хостинга, root-доступ, доступы к базе, пользователи CMS, временные админы, служебные аккаунты «для разработки» — всё это нужно пересмотреть. Если подрядчик остаётся на поддержке, ему выдают новый ограниченный доступ под новую роль, а не оставляют старый безымянный root.

С CMS похожая история. В WordPress, Bitrix, OpenCart, Drupal и самописных админках часто остаются пользователи бывших разработчиков, тестовые администраторы, слабые пароли, старые плагины и резервные архивы в публичных директориях. Приёмка проекта без проверки админов CMS — это приглашение к инциденту через самый очевидный вход.

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

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

1. Получить и подписать документы по правам и результатам работ.

2. Перевести домен и DNS под контроль заказчика.

3. Передать репозиторий в организацию или аккаунт заказчика.

4. Передать Figma-файлы и дизайн-библиотеки.

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

6. Развернуть проект из переданных материалов хотя бы на тестовом окружении.

7. Перевыпустить ключи, токены и пароли к внешним сервисам.

8. Удалить или ограничить доступы старой команды.

9. Проверить сайт, формы, платежи, почту, события аналитики и мониторинг.

10. Только после этого закрывать финальный платёж.

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

Финальная сверка зон риска

Главная мысль здесь не в недоверии к подрядчику. Нормальная передача прав и доступов на сайт защищает обе стороны. Заказчик получает управляемый актив, который можно развивать, продавать, переносить и проверять. Подрядчик закрывает проект без вечных просьб «пришлите пароль», «а где макет», «почему домен на вас». Спорить потом не о чем: объекты перечислены, права оформлены, доступы переданы, старые ключи отозваны.

Безопасная приёмка IT-проекта заканчивается подтверждённой сменой владельца на каждом узле — от записи у регистратора до owner-статуса в Figma. Расчёт до подтверждения этих точек оставляет у подрядчика рычаг, которого в завершённом проекте быть не должно.