Самая частая находка при смене подрядчика — домен, облачный аккаунт и репозиторий, оформленные на его юрлицо или на личную почту инженера, который уже уволился. Это редко бывает злым умыслом: в начале проекта кто-то регистрировал аккаунты быстрее всех, и им оказался подрядчик. Проблема в том, что обнаруживается это в самый неудобный момент — когда отношения уже закончились, а система работает.
Решается это одним документом. Перечень передаваемых доступов делается приложением к договору, заполняется в начале проекта, а не в конце, и обновляется на каждой сдаче этапа. В нём три колонки: позиция, на кого оформлено, как проверено. Пока в колонке «на кого оформлено» стоит название подрядчика, у вас есть незакрытый риск, и вы про него знаете.
Ниже — сам перечень из 12 позиций, правило владения аккаунтами, формулировка для договора, процедура проверки и отзыва доступов и порядок действий, если домен уже оформлен не на вас. Про полный пакет передачи системы — документацию, схему развёртывания, описание обменов — мы писали отдельно в материале про передачу системы в эксплуатацию; здесь речь только про учётные записи и владение ими.
Двенадцать позиций перечня
Список закрывает типовую систему: сайт, интеграции с учётом и CRM, внешние сервисы, почта. Если чего-то у вас нет — строка остаётся пустой с пометкой «не применяется», и это тоже результат: перечень должен быть полным, а не коротким.
| Позиция | На кого оформляется | Чем подтверждается переход |
|---|---|---|
| 1. Домен | Юрлицо заказчика, административный контакт — корпоративная почта | Вход в личный кабинет регистратора, письма о продлении приходят вам |
| 2. Управление DNS | Аккаунт заказчика у регистратора или в облаке | Самостоятельное изменение тестовой записи и её откат |
| 3. Хостинг и облако | Договор с провайдером и способ оплаты — на заказчика | Счета приходят вам, вы видите все проекты и можете добавить пользователя |
| 4. Репозиторий с кодом | Организация в аккаунте заказчика, подрядчик приглашён разработчиком | Вы владелец организации и можете отозвать доступ участнику |
| 5. Реестр образов и сборочная среда | Аккаунт заказчика | Сборка запускается из вашего аккаунта и завершается успешно |
| 6. База данных: административная учётная запись | Заказчик, отдельная учётка администратора | Подключение своим клиентом, снятие резервной копии и её восстановление |
| 7. Учётные записи администратора в 1С и CRM | Сотрудник заказчика, минимум одна на систему | Вход, создание и блокировка пользователя без участия подрядчика |
| 8. API-ключи маркетплейсов, телефонии, SMS | Аккаунты заказчика, ключи выпущены в них | Ключ перевыпускается вами, интеграция продолжает работать |
| 9. Платёжный шлюз и касса | Договор с провайдером на заказчика | Вход в кабинет, выгрузка операций, смена реквизитов выплат |
| 10. Почтовый домен и служебные ящики | Корпоративный почтовый сервис заказчика | Вы создаёте и удаляете ящики, видите настройки отправки |
| 11. Сертификаты и секреты | Хранилище на стороне заказчика | Перевыпуск сертификата и ротация одного секрета своими силами |
| 12. Аналитика и системы мониторинга | Аккаунты заказчика, подрядчик приглашён | Вы владелец счётчика и можете передать доступ третьей стороне |
Три позиции стоит выделить особо, потому что их пропускают чаще прочих. Реестр образов и сборочная среда — без них у вас есть код, но нет способа собрать из него работающую сборку. Сертификаты и секреты — то, что обычно живёт в личных заметках инженера и исчезает вместе с ним. Почтовый домен — через него ходят и уведомления клиентам, и письма о продлении всего остального, поэтому потеря именно его запускает эффект домино.
Карта из четырёх групп-блоков. «Имя и адрес»: домен, DNS, почтовый домен, сертификаты. «Инфраструктура»: хостинг и облако, репозиторий, реестр образов и сборочная среда, база данных. «Бизнес-системы»: административные учётки в 1С и CRM, платёжный шлюз и касса. «Внешние сервисы»: API-ключи маркетплейсов, телефонии и SMS, аналитика и мониторинг. У каждой позиции значок владельца с подписью «заказчик». От блока «почтовый домен» отходит пунктирная стрелка ко всем группам с подписью «через него приходят письма о продлении». Чертёжный стиль, подписи по-русски.
Правило владения: приглашают подрядчика, а не наоборот
Всё содержание перечня сводится к одному правилу, которое проще соблюдать, чем описывать. Аккаунт создаётся на корпоративный домен заказчика, а подрядчик получает именное приглашение с нужной ролью. Не «подрядчик заведёт и потом передаст» — передача аккаунта почти всегда упирается либо в правила сервиса, либо в то, что к аккаунту привязана ещё пара чужих проектов.
- Владелец — юрлицо, а не человек. Основной адрес аккаунта — общий корпоративный ящик вроде it@вашдомен, а не почта конкретного сотрудника, который может уволиться так же, как инженер подрядчика.
- Доступы именные. Каждый инженер подрядчика заходит под своей учётной записью, а не под общей. Иначе отзыв доступа одного человека означает смену пароля для всех и остановку работы.
- Роль по минимуму. Подрядчику нужна роль разработчика или администратора конкретного сервиса, а не владельца организации. Как это раскладывается по системам, разобрано в материале про принцип минимальных прав доступа.
- Второй фактор — на стороне заказчика. Если код подтверждения приходит на телефон подрядчика, аккаунт фактически его, кем бы он ни числился в перечне.
Возьмите любой сервис из перечня и попробуйте прямо сейчас удалить из него одного участника или сменить основной адрес аккаунта. Если это получается без обращения к подрядчику — позиция ваша. Если нужно кого-то просить — она не ваша, независимо от того, что записано в договоре. Проверку удобно делать не на расставании, а на сдаче каждого этапа, пока отношения рабочие.
Как это записывается в договоре
Передача доступов должна быть обязанностью с последствием, а не жестом доброй воли. Достаточно трёх формулировок, и ни одна из них не вызывает возражений у добросовестного подрядчика.
- 1Перечень — приложение к договору. «Состав передаваемых учётных записей и доступов определяется приложением, которое актуализируется при сдаче каждого этапа». Приложение подписывается вместе с договором, даже если половина строк на старте пустая.
- 2Передача — условие подписания акта финального этапа. «Акт по финальному этапу подписывается после передачи доступов в составе приложения и подтверждения заказчиком самостоятельного входа». Это единственная формулировка, которая реально работает: пока не оплачено, у подрядчика есть мотивация закрыть позиции.
- 3Отзыв доступов после сдачи. «В течение 5 рабочих дней после подписания акта заказчик отзывает доступы подрядчика, за исключением перечисленных в договоре поддержки». Обязанность здесь на заказчике — и это правильно, потому что отзывать доступ должен тот, у кого он и так есть.
Перечень становится приложением к акту финального этапа наравне с протоколом приёмочных проверок и составом документации — как это выглядит целиком, разобрано в материале про акт выполненных работ по разработке. Отдельно стоит помнить, что доступы и права на код — разные вещи: право можно передать, не передав ни одной учётной записи, и наоборот. Разбор второй половины вопроса — в статье о том, кому принадлежит исходный код.
Сравнение в две колонки. Левая — «Как бывает»: в центре блок «Аккаунт», владелец — «подрядчик, личная почта инженера», заказчик подписан как «приглашён, роль пользователя», второй фактор — на телефоне подрядчика; внизу ценник «124 000 ₽ при расставании». Правая — «Как надо»: владелец — «заказчик, корпоративный ящик it@», подрядчик подписан как «приглашён именно, роль разработчика», второй фактор — у заказчика; внизу подпись «4 рабочих часа на старте, около 12 000 ₽». Чертёжный стиль, подписи по-русски.
Проверка и отзыв: вход без подрядчика
Скриншот с логином и паролем в рабочем чате проверкой не является. Единственный честный способ убедиться, что доступ перешёл, — пройти по каждой позиции самому. На двенадцать позиций уходит около половины рабочего дня.
- 1Шаг 1. Войти под своей учётной записью
Не под переданной подрядчиком, а под учётной записью вашего сотрудника, созданной заранее. Вход выполняется с вашего устройства, второй фактор приходит на ваш телефон или в ваш корпоративный аккаунт.
- 2Шаг 2. Сменить пароль и убедиться, что ничего не сломалось
Смена пароля владельца — единственный способ проверить, что учётная запись действительно ваша. Заодно всплывают места, где пароль был вшит в настройки интеграции: если после смены что-то перестало работать, это найденная проблема, а не поломка.
- 3Шаг 3. Подтвердить права администратора
Создать и удалить тестового пользователя, изменить и вернуть одну настройку, добавить и убрать участника. Если хоть одно действие требует обращения к подрядчику, позиция не закрыта.
- 4Шаг 4. Отозвать лишние доступы и записать оставшиеся
После подписания акта из каждого сервиса удаляются учётные записи, которые больше не нужны. Те, что остаются для поддержки, вносятся в отдельный перечень договора поддержки с указанием роли и срока пересмотра. Как такие учётки накапливаются годами, мы разбирали в материале про забытые учётные записи подрядчика.
Просьба «отзовите нам доступы после сдачи» звучит вежливо и не работает по устройству: чтобы отозвать доступ, надо иметь права выше, чем у отзываемого. Если подрядчик может сам себя удалить и сам себе вернуть, права владельца остались у него. Отзыв — действие заказчика, и его выполнимость проверяется на шаге 3, а не в день расставания.
Если домен уже оформлен на подрядчика
Ситуация распространённая и решаемая, но платная. Опирается решение на две вещи: на договор, если в нём есть обязанность передать доступы, и на правила регистратора — у каждого есть процедура смены администратора домена по заявлению с подтверждающими документами. Отдельная сложность в том, что почтовый домен обычно живёт там же, и переносить приходится сразу оба.
- 1Зафиксировать текущее состояние: у какого регистратора домен, кто указан администратором, где размещены DNS-записи, какие почтовые ящики на домене работают. Это делается за час и без участия подрядчика — данные видны публично или в панели хостинга.
- 2Направить письменное требование о передаче со ссылкой на пункт договора. Формулировку и последствия отказа готовит юрист; наша часть — приложить перечень позиций и предложить конкретную дату.
- 3Параллельно готовить перенос: выгрузить DNS-записи, собрать список почтовых ящиков и правил пересылки, подготовить перевыпуск сертификатов и ключей внешних сервисов. Подготовка занимает 1–2 дня и делается до того, как передача состоится.
- 4После смены администратора сразу закрыть остальные позиции перечня и пройти проверку из четырёх шагов. Возвращаться к этому второй раз никто не станет.
Последняя строка расчёта считается так же, как экономия во всём проекте: 120 заявок в день, около 5 минут ручной обработки каждой, ставка менеджера 900 ₽/час — это 10 часов работы, то есть 9 000 ₽ за день. Двое суток без интеграции стоят 18 000 ₽ и обычно ещё некоторого количества потерянных заявок, которые в расчёт мы не берём, потому что честно посчитать их нельзя.
Диаграмма из двух столбцов. Левый низкий столбец — «Оформить на себя на старте: 4 часа, 12 000 ₽». Правый высокий столбец разбит на четыре сегмента с подписями: юрист 36 000 ₽, перенос почты и сертификатов 40 000 ₽, перевыпуск ключей 30 000 ₽, два дня ручной обработки заявок 18 000 ₽; общая подпись столбца — 124 000 ₽. Между столбцами вертикальная подпись «разница примерно в десять раз». Ось — рубли, подписи по-русски.
Когда перечень из двенадцати позиций избыточен
Полный перечень нужен там, где система будет жить годами и переживёт хотя бы одну смену исполнителя. В трёх случаях он превращается в бумагу ради бумаги.
- Вся автоматизация внутри купленного сервиса. Если настройка сделана в вашей CRM и никакой отдельной инфраструктуры нет, из перечня остаются две строки: административная учётка и список интеграционных ключей. Остальные позиции не существуют.
- Разовая работа без эксплуатации. Выгрузка, отчёт, миграция данных — сделали, проверили, забыли. Здесь важнее не перечень доступов, а то, чтобы подрядчику не выдали лишнего на время работ: об этом мы писали в материале про доступы подрядчику при внедрении.
- Пилот на тестовом контуре. Пока проект живёт на тестовых данных и его судьба не решена, заводить двенадцать аккаунтов на юрлицо преждевременно. Но момент перехода пилота в эксплуатацию — это ровно та точка, где перечень нужно завести, и пропускают её чаще всего.
И честное ограничение. Закрытый перечень не означает, что вы можете обслуживать систему сами. Он означает только, что вас никто не держит: любая команда сможет войти и продолжить. Сама способность продолжить — это документация, тесты и понятная архитектура, и стоит она отдельных денег на разработке, а не в момент передачи.
