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

Кому и когда это нужно

Подрядчик сделал, всё работает, вы на связи в мессенджере. Вопрос появляется в день, когда он не отвечает сутки, поднял цену, ушёл в отпуск или закрыл ИП. Тогда выясняется, что домен продлевается с его карты, сервер оформлен на него, код лежит в его личном репозитории, а пароли остались в переписке. Общую картину зависимости я разбирал в статье про зависимость от подрядчика, про домен есть отдельный разбор возврата. Здесь только список: что должно лежать у владельца. Я сам подрядчик и советую заказчику требовать этого с первого дня. Это обычная гигиена, а не недоверие. Если не заняться, любая пауза у исполнителя превращается в простой бизнеса, а любой спор о деньгах идёт с чужим ключом от вашего сайта на руках.

Как это делается: 9 шагов

1. Заведите реестр «что где»: система, на чьём аккаунте, кто имеет доступ, когда продлевать. Начните с того, что останавливает продажи: домен, сервер, бот, приём оплаты.
2. Переведите владение: регистратор, хостинг, платёжный кабинет и сервисы на вас или компанию. Подрядчик получает роль пользователя с нужными ему правами.
3. Репозиторий создайте в организации владельца (GitHub, GitLab или свой git-сервер). Подрядчик там участник, а не хозяин.
4. Секреты храните в менеджере паролей с общим хранилищем и раздельными правами, про выбор есть статья про менеджер паролей. В переписке и в коде паролей нет.
5. Потребуйте документацию: README (как запустить, где лежит, как выкатить и откатить), схема данных, список интеграций, список переменных окружения без значений.
6. Узнайте про копии: где лежат, как часто делаются, как долго хранятся и когда последний раз восстанавливали из них. Копия на том же сервере, что и база, не спасёт от потери сервера. Подробнее в статье про резервные копии.
7. Выясните, кто узнает о падении. Уведомление должно приходить не только подрядчику.
8. Проведите контрольный тест: подрядчик, а лучше другой разработчик, разворачивает проект с нуля на чистой машине только по README. Что не получилось, дописывается в документацию.
9. Дайте минимум прав и заранее решите, что делаете в день ухода подрядчика.

Чек-лист «кому принадлежит»

Список на день ухода подрядчика: сменить пароли и токены (бота, API, базы), убрать его SSH-ключи и участие в репозитории, пройти по реестру, забрать документацию и последние копии, запустить контрольный тест.

Законы и документы

По ст. 1296 ГК РФ право на программу, созданную по заказу, принадлежит заказчику, если договор не предусматривает иное (проверено в справочной системе «Консультант»). Договор часто предусматривает иное или молчит про доступы. Пропишите обязанность передать код, доступы и документацию при приёмке и при расторжении, а также конфиденциальность. Права на код решают договор и закон, покажите текст юристу. Заодно спросите, на каких условиях подрядчик вправе использовать написанные им библиотеки в других проектах, это тоже лучше записать.

Если подрядчик видит базу клиентов, он обрабатывает персональные данные по вашему поручению. По 152-ФЗ, ст. 6 ч. 3 (сверено по справочным системам «Консультант» и «Гарант»), в поручении указывают перечень данных и действий, цели, конфиденциальность и требования к защите по ст. 19, а перед клиентом отвечаете вы как оператор. Саму ст. 19 целиком я не открывал. Подробности в статье про мифы о 152-ФЗ.

Где ошибаются чаще всего

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

Пароли отправляют в мессенджер, а потом не меняют. После ухода подрядчика старые ключи остаются рабочими.

Резервная копия лежит на том же сервере, а восстановление ни разу не проверяли. Это половина копии.

Документацию просят в конце проекта. К тому времени её никто не пишет. Просите README вместе с первым релизом и дополняйте с каждым.

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

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

Где здесь поможет автоматизация

Я делаю аудит передачи (сверяю реестр и права), собираю документацию, переношу проект на аккаунты владельца, настраиваю мониторинг и бэкапы, подробнее в разделе про IT-аудит. Что есть в моих проектах: README с установкой и файл с примером переменных окружения, деплой-скрипты в папке проекта. В одном из ботов сторож по расписанию раз в 2 минуты проверяет бота и сервер и пишет администраторам в Telegram, одну и ту же проблему не чаще раза в час. В CRM под одного заказчика база и файлы копируются ежедневно по расписанию, копии хранятся 14 дней. Восстановление из них проверяйте отдельно.

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

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

Подрядчик говорит, что безопаснее держать доступы у него. Что ответить?

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

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

Контрольным тестом: развернуть проект с нуля на чистой машине только по README. Если застряли, документации не хватает.

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

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

Коротко о главном

Заведите реестр «что где», переведите аккаунты на владельца, потребуйте README и контрольный тест, проверьте копии и оповещения, закрепите передачу в договоре.

Хотите, чтобы я проверил, что у вас лежит у владельца, собрал документацию и перенёс проект на ваши аккаунты? Напишите мне в Telegram слово «ЗАЛОЖНИК».