Статья, это подробный разбор на личном примере о том, как отсутствие формальных процедур и контрольных точек в проектной работе приводит к полной потере результатов. Это не про «проморгать срок» или «попасть на деньги», а про системную уязвимость, когда работа де-факто не является твоей. Принципы, о которых здесь пойдёт речь, напрямую пересекаются с требованиями к управлению доступом и защите информации, знакомыми по 152-ФЗ, только в масштабе одного человека.
Результат полугодовой работы над проектом для небольшой компании исчез в один день. Не из-за сбоя диска, не из-за злого умысла, а из-за одного письма от системного администратора заказчика. Весь код, конфигурации, документация — доступ к этому был закрыт для меня в течение нескольких часов. История банальна, но её последствия заставляют пересмотреть не только подход к работе с заказчиками, но и базовое понимание того, что такое «твой» проект.
Проект, который казался идеальным
Заказчик — производственная компания среднего размера. Проект — разработка системы внутреннего документооборота с элементами workflow. Работа велась удалённо, общение через корпоративный мессенджер и редкие созвоны. На первый взгляд, всё было прозрачно: техническое задание согласовано, этапы выделены, оплата по факту завершения каждого этапа. Работа шла в инфраструктуре заказчика: выделенный сервер, корпоративный GitLab, Jira для задач.
На начальном этапе это казалось преимуществом. Не нужно тратить свои ресурсы, всё развёрнуто и готово к работе. Доступы были предоставлены по запросу: учётная запись в AD, права разработчика в GitLab, доступ к серверу по SSH. Никаких дополнительных соглашений о передаче прав на код или процедурах завершения проекта не подписывалось. Устная договорённость: «Сделаем — вы всё получите».
Основная ошибка была в этой самой «прозрачности». Полная интеграция в чужую инфраструктуру без формального закрепления статуса и прав на создаваемые артефакты, это не сотрудничество, это временное использование ресурсов, которое может быть прекращено в любой момент по внутренним правилам этой инфраструктуры.
Точка невозврата: письмо от сисадмина
Проект был близок к завершению. Оставалось провести финальное тестирование и передать документацию. В этот день пришло стандартное, ничем не примечательное письмо от отдела информационной безопасности компании-заказчика. В рамках плановой ротации паролей и аудита доступов моя учётная запись была признана неактуальной и отключена. Письмо содержало вежливую просьбу, в случае если доступ ещё требуется, связаться с непосредственным руководителем для повторного согласования.
Руководитель проекта со стороны заказчика к тому моменту находился в длительном отпуске без возможности оперативной связи. Обращение к его заместителю не дало результата: «Мы видим, что проект вроде как завершён, но без [имя руководителя] мы не можем ничего решить по доступам. Подождёте его выхода».
Ожидание растянулось на три недели. За это время все попытки достучаться до кого-либо упирались в корпоративные процедуры. К моменту возвращения руководителя внутренняя проверка выявила, что проект, по факту, не был официально принят актом, а значит, формально не существует. Было принято решение не восстанавливать доступ внешнему специалисту, а поручить доработку и внедрение внутренней IT-команде на основе «оставшихся наработок». Мои права на результаты работы не были юридически зафиксированы, поэтому оспаривать что-либо не имело смысла.
Что было потеряно на самом деле
Потеря, это не только исходный код. Это комплексный продукт, состоящий из нескольких слоёв, каждый из которых был недоступен после блокировки.
- Исходный код. Основная кодовая база в GitLab. Без доступа к репозиторию нет истории коммитов, веток, merge request’ов. Локальные копии, конечно, остались, но они отставали от актуальной версии на сервере как минимум на несколько дней финальных правок.
- Инфраструктура и конфигурация. Скрипты развёртывания (Dockerfile, docker-compose.yml, Ansible playbooks), конфигурационные файлы для серверов (nginx, systemd units), переменные окружения. Большая часть этой конфигурации никогда не выгружалась локально, так как настройка велась напрямую на тестовом стенде.
- Данные и миграции. Схемы базы данных, скрипты миграций, тестовые дампы. Всё это хранилось на том же сервере и в CI/CD пайплайнах GitLab.
- Документация. Внутренняя wiki проекта, где велись спецификации API, архитектурные решения, инструкции по развёртыванию. Ключевые моменты, принятые в ходе разработки, остались там.
- История коммуникации и решений. Задачи, обсуждения в merge requests, комментарии в Jira. Контекст многих технических решений был утерян.
Фактически, осталась только локальная копия основной ветки кода, которую можно сравнить с книгой, из которой вырваны все страницы, кроме каждой третьей. Собрать работоспособную систему из этих обрывков было невозможно.
Проекция на требования регуляторики: где были пробелы
Ситуация, при которой лицо, создающее информацию (артефакт), не контролирует среду её хранения и не имеет гарантированного доступа к ней, прямо противоречит базовым принципам защиты информации. Если спроецировать эту историю на требования 152-ФЗ или даже на внутренние политики ФСТЭК, становятся видны системные нарушения.
| Принцип / Требование | В проектной работе (на моём примере) | Как должно быть |
|---|---|---|
| Разграничение прав доступа | Права были выданы «под проект» без чёткого срока и привязки к артефактам. Отзыв произошёл по общему правилу (ротация), а не по событию завершения проекта. | Доступ должен предоставляться на основе роли (разработчик) к конкретным ресурсам (репозиторий X, сервер Y). Срок действия доступа привязан к этапу проекта или договору. Отзыв — отдельная процедура, инициируемая руководителем проекта, а не автоматическим скриптом. |
| Учёт и управление активами | Созданные программные активы (код, конфиги) не были идентифицированы как активы, принадлежащие мне как исполнителю, на время разработки. Они сразу стали «собственностью» среды хранения. | Должен вестись реестр активов проекта с указанием создателя, владельца на разных этапах и места хранения. Права передаются по акту приёмки. |
| Непрерывность деятельности | Потеря доступа к среде разработки парализовала работу полностью. Не было резервной копии, контрольной точки, из которой можно было бы продолжить. | Для ключевых артефактов (код, конфигурация) должна быть предусмотрена процедура регулярного выгруза и хранения в нейтральном, контролируемом исполнителем месте. Это аналог backup & recovery. |
| Инцидент-менеджмент | Отзыв доступа не был классифицирован как инцидент, нарушающий ход проекта. Не было процедуры эскалации и восстановления. | Любое незапланированное прекращение доступа ключевого исполнителя должно запускать процедуру инцидент-менеджмента с определением ответственных и временем на реакцию. |
Суть в том, что даже в небольшом проекте должны существовать формальные, пусть и минимальные, «регламенты». Их отсутствие делает всю работу заложником человеческого фактора и внутренних процессов заказчика.
Практические шаги защиты: что делать по-другому
Извлечённые уроки можно свести к набору конкретных правил, которые теперь являются обязательными в любой проектной работе.
1. Юридический каркас: договор и приложения
Даже для небольшого заказа должен быть договор или подробное техническое задание, выступающее как оферта. Ключевые пункты, которые нужно включить:
- Права на результаты интеллектуальной деятельности (РИД) до момента полной оплаты. Прописать, что исключительные права на создаваемый код и документацию остаются за исполнителем до подписания акта сдачи-приёмки и осуществления финального платежа. Это даёт легитимное основание для защиты своих активов.
- Порядок предоставления и отзыва доступов. Чётко указать, какие доступы необходимы (к каким системам), кто их предоставляет, и что их отзыв до завершения проекта возможен только по обоюдному согласию сторон или является нарушением условий с определёнными последствиями (например, приостановка работ).
- Порядок приёмки и передачи артефактов. Детально описать, что входит в передачу: не только код, но и конфигурация, документация, базы данных. Указать формат и место передачи (например, архив на нейтральном облачном хранилище или передача на физическом носителе).
2. Техническая независимость: контроль над артефактами
Философия «ничего личного, только бизнес» должна применяться к инфраструктуре.
- Свой репозиторий — источник истины. Основной репозиторий проекта должен быть на нейтральной платформе (GitLab, GitHub) под вашим контролем или на платформе, где вы являетесь явным владельцем организации/группы. Заказчику предоставляется доступ на чтение/запись. Все изменения интегрируются сюда. Это гарантирует, что код всегда ваш. Работа в репозитории заказчика допустима только как mirror или для CI/CD.
- Регулярный выгруз и резервное копирование всего. Установите правило: в конце каждой недели или этапа весь проект (код, конфиги, скрипты развёртывания, документация) архивируется и помещается в хранилище, которое контролируете только вы (личное облако, другой хостинг). Это ваша точка восстановления.
- Инфраструктура как код (IaC) в вашем репозитории. Все описания инфраструктуры (Docker, Terraform, Ansible) должны храниться в вашем основном репозитории и разворачивать среду заказчика «с нуля». Это минимизирует зависимость от уникальных настроек его серверов.
# Пример структуры проекта, обеспечивающей независимость
/my-project-repo/
├── src/ # Исходный код
├── infra/ # Инфраструктура как код (Docker, k8s манифесты)
├── configs/ # Конфигурации для различных сред
├── docs/ # Документация (в markdown)
├── backups/ # .gitignore, но сюда скриптом складываются weekly snapshots
└── deploy_scripts/ # Скрипты развёртывания
3. Процедурные контрольные точки
Проект должен управляться не только по задачам, но и по состояниям артефактов.
- Еженедельный синхрон-статус. Краткое письменное резюме: что сделано, что в работе, какие артефакты обновлены, ссылка на актуальный коммит в вашем репозитории. Это создаёт историческую ленту и фиксирует прогресс.
- Материальная передача по этапам. По завершении каждого этапа, даже промежуточного, формировать и передавать заказчику (например, по email) конкретный артефакт: архив с кодом на момент завершения этапа, отчёт о выполненной работе. Это формализует прогресс и создаёт «вещественные доказательства» выполненной работы.
- Чёткий критерий завершения. В техническом задании должен быть абсолютно ясный, объективно проверяемый критерий завершения проекта (например, «система проходит все тесты из чек-листа, размещённого в приложении 2»), а не размытые формулировки вроде «внедрение и запуск в промышленную эксплуатацию».
Заключение: ваш проект, это то, что вы можете защитить
История с потерей доступа, это не частный случай плохого заказчика. Это демонстрация системного риска, присущего модели, где исполнитель делегирует контроль над средой и результатами другой стороне. В IT-регуляторике подобные риски mitigated (снижаются) через политики, регламенты и технические меры. В проектной работе фрилансера или небольшой команды эти меры ложатся на самого исполнителя.
Ключевой вывод: ценность представляют не часы, проведённые за компьютером, а материализованные, защищённые и передаваемые артефакты. Проект по-настоящему принадлежит вам только тогда, когда вы можете доказать это право и технически продолжить работу над ним даже в случае полного разрыва всех каналов связи с заказчиком. Всё остальное — временное использование ресурсов, результат которого может в любой момент перестать быть вашим. Формализация, контроль над источниками и процедурные точки, это не бюрократия, а единственная реальная защита от подобных ситуаций.