Кажется, выстраиваешь стартап на доверии, а потом внезапно обнаруживаешь, что главный технический специалист… не оставил тебе даже пароля от GitHub. Ни в шутку, ни в полсилы. Всё, с чем работала команда: домены, серверы, CI/CD, база клиентов, мониторинг - оказалось привязано к личным аккаунтам подрядчика. Контроль потерян. А вернуть всё не факт, что возможно.

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

Почему это случается: техбэкдор как следствие «слепой зоны»

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

Сначала ради скорости. Потом из-за инерции.

Такой человек легко берёт на себя «технический фундамент»:

• регистрирует домены и DNS на себя,

• разворачивает облачные окружения на личные аккаунты,

• админит весь стек — от CI/CD до логов,

• получает root-доступ ко всем машинам,

• интегрирует сторонние API через личные кабинеты,

• не делится документацией (или делает это в конце, в лучшем случае).

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

Что делать, если уже поздно: выгорание, ссора или просто тишина

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

Компания пошла в суд. Увы, решение было в пользу подрядчика: никаких письменных соглашений о передаче прав на инфраструктуру, данных или аккаунт не было.

В другом кейсе аналогичная история, но с GitHub: разработчик ушёл в тень, а доступы остались только у него. Открытый репозиторий, история коммитов - всё потеряно. Проект пришлось переписывать заново.

Когда инфраструктура не «отвязана» от личности, последствия могут быть катастрофическими. Это не только срыв релиза, но и риски по ИБ, нарушения 152‑ФЗ, утечки данных, недопоставка заказчику. А значит — штрафы, репутационные потери, запрет на участие в торгах или даже уголовка.

Как обезопасить бизнес: превентивные меры, которые спасают от зависимости

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

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

2. Контроль. Аккаунты создаёт и управляет ими юридическое лицо.

3. Прозрачность. Есть сквозная документация: что где развернуто, с какими параметрами, кто имеет доступ.

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

5. Процедура выхода, как минимум два условия:
   – возвращение всех доступов и материалов;
   – финальный аудит инфраструктуры (можно сделать чек-лист).

Ещё хорошая практика role-based access control. Например, фрилансер может иметь доступ к staging-серверу, но не к продакшену.

И самое важное не экономить на time-to-contract. Хороший юрист, разбирающийся в IT и IP, убережёт от убытков на миллионы.

А что, если фрилансер - это друг? Или бывший партнёр?

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

Поэтому даже если человек  «свой», договор и архитектура безопасности нужны. Если же вы тот самый фрилансер или CTO «по дружбе», стоит также подумать о своей защите: что вы передаёте, в каком виде, на каких условиях. Это сохранит отношения. И бизнес.

Что вы думаете?

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