Кажется, выстраиваешь стартап на доверии, а потом внезапно обнаруживаешь, что главный технический специалист… не оставил тебе даже пароля от GitHub. Ни в шутку, ни в полсилы. Всё, с чем работала команда: домены, серверы, CI/CD, база клиентов, мониторинг - оказалось привязано к личным аккаунтам подрядчика. Контроль потерян. А вернуть всё не факт, что возможно.
И самое болезненное: с юридической точки зрения уязвимы не только основатели, но и инвесторы, заказчики, партнёры. Ни один NDA тут не спасёт, если изначально не были расставлены границы доступа, конкретный перечень информации и ответственности. В этом тексте не морализаторство, а подробный разбор, как такие истории случаются, чем они грозят и что можно сделать заранее, чтобы однажды не зависеть от настроения одного человека.
Почему это случается: техбэкдор как следствие «слепой зоны»
Когда стартап маленький, и в команде все «на ты», юридический контур последнее, о чём думают. Приглашается фрилансер или DevOps-специалист, и он быстро становится незаменимым: всё держится на его опыте, скиле и доброй воле.
Сначала ради скорости. Потом из-за инерции.
Такой человек легко берёт на себя «технический фундамент»:
регистрирует домены и DNS на себя,
разворачивает облачные окружения на личные аккаунты,
админит весь стек — от CI/CD до логов,
получает root-доступ ко всем машинам,
интегрирует сторонние API через личные кабинеты,
не делится документацией (или делает это в конце, в лучшем случае).
С юридической точки зрения всё, что настроено принадлежит тому, кто это создал, если нет других договорённостей и зафиксированных указаний. А это значит, что в любой момент он может отключить инфраструктуру, удалить аккаунты, «потерять» доступ или просто пропасть. И будет сложно это разгребать.
Что делать, если уже поздно: выгорание, ссора или просто тишина
Такие истории не редкость. Вот пример.
Компания развивала маркетинговую платформу, у которой вся аналитика, визуализация данных и клиентский интерфейс были развёрнуты на AWS. Всё работало через личный аккаунт подрядчика, потому что «так быстрее». Когда возник конфликт из-за сроков, подрядчик закрыл доступ к консоли. Через пару дней выкатил счёт за досрочное расторжение.
Компания пошла в суд. Увы, решение было в пользу подрядчика: никаких письменных соглашений о передаче прав на инфраструктуру, данных или аккаунт не было.
В другом кейсе аналогичная история, но с GitHub: разработчик ушёл в тень, а доступы остались только у него. Открытый репозиторий, история коммитов - всё потеряно. Проект пришлось переписывать заново.
Когда инфраструктура не «отвязана» от личности, последствия могут быть катастрофическими. Это не только срыв релиза, но и риски по ИБ, нарушения 152‑ФЗ, утечки данных, недопоставка заказчику. А значит — штрафы, репутационные потери, запрет на участие в торгах или даже уголовка.
Как обезопасить бизнес: превентивные меры, которые спасают от зависимости
Самое разумное - выстроить архитектуру взаимодействия по модели «независимой инфраструктуры». Что это значит:
Доступы. Предоставляются через корпоративные аккаунты, не через личные. И если этим занимается сотрудник, то лучше потратить время на подготовку и внедрение регламента по работе с этим и ознакомить с ним сотрудника. Должностная инструкция с соответствующими обязанностями также не помешает.
Контроль. Аккаунты создаёт и управляет ими юридическое лицо.
Прозрачность. Есть сквозная документация: что где развернуто, с какими параметрами, кто имеет доступ.
Правила. В договоре чётко прописано: всё, что сделано в рамках проекта, включая конфигурации, код, пайплайны и доступы, — интеллектуальная собственность заказчика, права на которые переходят в момент ее передачи.
Процедура выхода, как минимум два условия:
– возвращение всех доступов и материалов;
– финальный аудит инфраструктуры (можно сделать чек-лист).
Ещё хорошая практика role-based access control. Например, фрилансер может иметь доступ к staging-серверу, но не к продакшену.
И самое важное не экономить на time-to-contract. Хороший юрист, разбирающийся в IT и IP, убережёт от убытков на миллионы.
А что, если фрилансер - это друг? Или бывший партнёр?
Это самая тонкая зона. Личный уровень доверия может заслонить юридическую небрежность. Но тут стоит вспомнить простое правило: любой человек может поменяться. Не потому что злой, а потому что что-то изменилось.
Поэтому даже если человек «свой», договор и архитектура безопасности нужны. Если же вы тот самый фрилансер или CTO «по дружбе», стоит также подумать о своей защите: что вы передаёте, в каком виде, на каких условиях. Это сохранит отношения. И бизнес.
Что вы думаете?
Бывали ли у вас случаи, когда ключевая инфраструктура уходила вместе с человеком? Как вы защищаете себя сейчас — и какие уроки усвоили на чужом или своём опыте?
Давайте обсудим, рефлексия и разбор чужих кейсов здесь особенно полезны.
