Работа с ИТ-подрядчиком: договор, NDA и передача доступов

Работа с ИТ-подрядчиком безопасна тогда, когда в договоре описан результат, а не только процесс, в NDA указано, какие данные считаются конфиденциальными, а доступы выданы персонально, с минимальными правами и с возможностью быстро отозвать. Если эти три вещи оформлены до старта, споры о сроках и исходном коде обычно остаются мелкими. Ниже разбор того, что я проверяю в таких документах и как организую передачу доступов.

С чего начинается договор с ИТ-подрядчиком

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

Плохо: «разработка сайта». Лучше: «разработка сайта в объёме технического задания (приложение 1), включая перечень страниц, форм, интеграций и требований к скорости загрузки». Техническое задание превращается в приложение, на которое ссылается договор, и тогда любое «а мы думали, это тоже входит» проверяется по документу. О том, как составить такое приложение, я писал отдельно: техническое задание на сайт.

Что ещё должно быть в основной части:

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

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

Кому принадлежат исходный код, сайт и данные

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

В договоре стоит прямо описать:

1. Что передаётся заказчику по завершении: исходный код, база данных, документация по развёртыванию, учётные записи.
2. На каких условиях передаются исключительные или неисключительные права на результат. Здесь нужен юрист, потому что детали зависят от вида работ и применимого законодательства.
3. Что делать со сторонними компонентами: библиотеки с открытыми лицензиями, платные плагины, шаблоны. Лицензии на них не принадлежат ни подрядчику, ни вам, они действуют по своим условиям.
4. Кто является владельцем доменного имени, облачного аккаунта и репозитория. Мой подход: всё, что можно, регистрируется на заказчика с первого дня, а подрядчик получает доступ как участник.

Проверка простая. Задайте себе вопрос: если подрядчик завтра пропадёт, сможет ли другая команда поднять проект за разумное время? Если ответ «нет», в договоре что-то упущено.

Что должно быть в NDA и чем оно не является

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

Хорошее NDA содержит:

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

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

Как безопасно передать доступы подрядчику

Самая частая ошибка: прислать логин и пароль администратора в мессенджере или по почте. Пароль живёт в переписке годами, и никто не помнит, у кого он ещё остался.

Правила, которых я придерживаюсь:

• Персональные учётные записи. Каждому специалисту своя запись, а не общий логин «admin». Тогда в журнале видно, кто что делал, а отзыв доступа не ломает работу остальных.
• Минимальные права. Разработчику сайта обычно не нужен доступ к бухгалтерии и корпоративной почте. Если задача касается одного сервера, права выдаются на него одного.
• Передача через менеджер паролей или общий защищённый сейф, а не через чат. Если менеджера нет, как минимум разделяйте логин и пароль по разным каналам и сразу меняйте пароль после первого входа.
• Двухфакторная аутентификация для всех учётных записей, где она доступна. Подробнее про правила для компании: пароли и двухфакторная аутентификация.
• Ограничение по времени. Доступ выдаётся на срок проекта или этапа, дальше продлевается осознанно.
• Тестовая среда. Если возможно, подрядчик работает в копии, а не в боевой системе. Копия не должна содержать реальные персональные данные, либо данные нужно обезличить.

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

Как вести учёт доступов и что делать при завершении работ

Заведите простой реестр: система, учётная запись, кому выдана, какие права, дата выдачи, дата планового отзыва. Таблица в обычном документе подойдёт. Главное, чтобы реестр обновлялся, а не заполнялся один раз.

При завершении проекта или смене подрядчика выполняется короткий чек-лист:

1. Отозвать все персональные доступы подрядчика, включая ключи SSH и токены API.
2. Сменить общие пароли и секреты, которыми он пользовался (пароли баз данных, ключи интеграций, токены ботов).
3. Проверить, что на сторонних сервисах (хостинг, домен, почта, репозиторий) владельцем остаётся ваша организация.
4. Получить итоговую документацию и убедиться, что по ней можно развернуть проект.
5. Запросить подтверждение об удалении ваших данных с рабочих устройств подрядчика, если это предусмотрено NDA.

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

Как не потерять контроль над ходом проекта

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

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

Если проект большой и в нём участвует несколько ролей, пригодится описание этапов и рисков, об этом подробнее в статье про управление ИТ-проектом.

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

Нужно ли NDA, если подрядчик делает обычный сайт?

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

Можно ли отдать подрядчику пароль владельца аккаунта?

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

Что делать, если подрядчик не хочет передавать исходный код?

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

Как проверить, что подрядчику можно доверять?

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

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