Что писать в NDA про доступ подрядчика к серверу

MAATRIX

Важная оговорка сразу: это не готовый юридический шаблон и не текст для копирования в договор. Ниже — обзор того, какая логика обычно стоит за типичными пунктами NDA при доступе подрядчика к серверу, чтобы вы понимали, зачем нужен каждый пункт и что он должен закрывать по смыслу. Формулировки, применимые в вашей юрисдикции и к вашей ситуации, должен готовить или как минимум проверять юрист — самостоятельно составленный «юридический» текст без такой проверки рискует не защищать вас вообще.

Зачем вообще NDA, если подрядчику и так доверяют

Когда фрилансер или подрядная команда получает SSH-доступ к серверу — на настройку, аудит, миграцию или разовый фикс — вместе с доступом к системе они автоматически получают доступ ко всему, что на этой системе есть: коду, конфигам, учётным данным других сервисов, а часто и к данным пользователей в базе. Устная договорённость «ну вы же понимаете, что это конфиденциально» не работает по двум причинам: подрядчик может искренне не считать что-то конфиденциальным (например, структуру инфраструктуры или список используемых сервисов), а если что-то всё же произойдёт — утечка, слив базы, публикация конфигов — у вас не будет документа, на который можно опереться. NDA (соглашение о неразглашении) закрывает именно этот пробел: он проговаривает вслух, что именно нельзя разглашать, как можно использовать доступ и что будет, если правила нарушены.

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

Что считать конфиденциальной информацией в контексте доступа к серверу

Самая частая ошибка в NDA для доступа к серверу — слишком общая формулировка вроде «вся информация, полученная в ходе работ, является конфиденциальной». Звучит защитно, но на практике такая формулировка либо трактуется судом слишком широко и потому неисполнимо, либо, наоборот, подрядчик легко докажет, что конкретный факт (например, «на сервере используется nginx») не подпадал под неё, потому что это общедоступная техническая информация.

Имеет смысл прямо перечислить категории того, что относится к конфиденциальной информации именно в контексте доступа к серверу, а не к работе с компанией вообще:

• Учётные данные доступа — пароли, приватные SSH-ключи, токены API, данные для входа в панели управления, VPN-конфиги. Это не то же самое, что «код» — про учётки часто забывают, хотя именно они дают прямой доступ к инфраструктуре.
• Структура и архитектура инфраструктуры — какие сервисы развёрнуты, как они связаны, какие порты открыты наружу, схема сети, используемые внутренние адреса. Для конкурента или злоумышленника это готовая карта для атаки, даже без единой строчки кода.
• Исходный код и конфигурационные файлы — не только приложения, но и файлы веб-сервера, systemd-юнитов, cron-задач, скриптов деплоя — в них часто прописаны пути, внутренние адреса и иногда прямые секреты.
• Данные пользователей, до которых подрядчик технически может дотянуться — даже если задача подрядчика не связана напрямую с этими данными. Если у него есть доступ к базе или к файловой системе, где эти данные лежат, физическая возможность их увидеть уже есть, и NDA должен закрывать именно возможность доступа, а не только «данные, которые подрядчик специально запрашивал».
• Сам факт и детали работ — иногда важно указать отдельно, что нельзя публично упоминать («сделал аудит безопасности для компании N») без согласия, если это может навести третьих лиц на мысль об уязвимостях.

Логика в том, чтобы перечисление было конкретным и привязанным к реальному техническому контексту задачи, а не скопированным из шаблона NDA для, скажем, разработки мобильного приложения. Что именно перечислять — зависит от того, к чему у подрядчика реально есть доступ: если он работает только с одним контейнером в изолированной среде, вряд ли стоит писать про «всю инфраструктуру компании», а если у него root на проде — сокращать список тоже не стоит.

Явное ограничение цели использования доступа

Отдельный и часто упускаемый пункт — не что нельзя разглашать, а для чего вообще можно использовать сам доступ. Логика простая: доступ выдаётся не «вообще», а под конкретную задачу — настроить бэкапы, починить конфиг nginx, провести миграцию базы. Всё, что выходит за рамки этой задачи, — уже использование доступа не по назначению, даже если формально ничего не «разглашено».

Смысл пункта — прямо зафиксировать, что доступ предоставляется исключительно для выполнения оговорённых работ по конкретному договору или заданию, и не может использоваться в каких-либо иных целях: ни для параллельного анализа инфраструктуры «на будущее», ни для тестирования собственных инструментов на чужом сервере, ни тем более для действий в интересах третьих лиц. Это защищает от ситуации, когда подрядчик формально ничего не нарушил (не слил данные, не рассказал никому), но использовал полученный доступ шире, чем предполагалось — например, скопировал себе «на всякий случай» структуру базы для похожего проекта у другого клиента.

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

Запрет на сохранение копий и передачу доступа третьим лицам

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

Логика этого пункта — обязательство подрядчика по завершении работ удалить все локальные копии конфиденциальной информации (базы, дампы, конфиги, ключи), которые не являются согласованным результатом работ (например, финальный код проекта, который по договору передаётся заказчику, — это не то же самое, что рабочие копии для отладки). Отдельно стоит зафиксировать запрет на передачу самого доступа третьим лицам: субподрядчикам, коллегам, «на минуту показать другу разработчику». Доступ выдан конкретному человеку или конкретной команде под конкретную задачу — и передача учётных данных кому-то ещё, даже без злого умысла, размывает всю модель ответственности: вы больше не знаете, кто реально имеет доступ к вашему серверу.

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

Обязанность немедленно уведомить о найденной уязвимости

Этот пункт стоит отдельно, потому что он регулирует не утечку, а находку. Подрядчик, работающий с сервером, рано или поздно натыкается на что-то, что не входило в его задачу: устаревшую версию софта с известной CVE, забытый открытый порт, слабый пароль в другом сервисе, файл с секретами не в том месте. Здесь есть развилка: либо подрядчик молча проходит мимо (и вы остаётесь с непонятой уязвимостью), либо начинает «чинить» найденное самостоятельно, без согласования — что тоже опасно, потому что несогласованные изменения на проде могут сломать что-то ещё сильнее, чем сама уязвимость.

Логика пункта — обязательство немедленно уведомить заказчика о любой обнаруженной уязвимости или проблеме безопасности, не входящей в рамки текущего задания, и не предпринимать самостоятельных действий по её устранению без согласования, кроме случаев прямой и явной угрозы (и то — с последующим быстрым уведомлением). Это не только вопрос доверия, но и практики: заказчик должен решать, чинить ли найденное силами того же подрядчика (за дополнительную оплату), привлекать другого специалиста, или устранять своими силами — а не узнавать постфактум, что кто-то «уже всё поправил» неизвестным образом.

Отдельно полезно указать канал и срок уведомления — не «когда-нибудь в отчёте по итогам работ», а в разумный короткий срок после обнаружения, особенно если речь о критичной уязвимости.

Срок действия обязательств о конфиденциальности

Частая ошибка — считать, что обязательства NDA действуют, пока действует сам договор на работы, и автоматически заканчиваются вместе с ним. Логически это неверно: то, что подрядчик узнал о вашей инфраструктуре во время работ, не перестаёт быть чувствительным в день подписания акта. Пароли можно сменить сразу, но структуру системы, список уязвимых мест, данные, которые он видел, — «отозвать» из его памяти невозможно.

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

Ответственность за нарушение условий NDA

NDA без последствий за нарушение — это просто документ о добрых намерениях. Логика этого пункта в том, чтобы явно указать, что происходит, если условия нарушены: какая ответственность наступает (обычно — материальная, в виде компенсации убытков, которые сложно доказать точной цифрой, поэтому часто используются фиксированные штрафные суммы или неустойка), и какие действия заказчик вправе предпринять при обнаружении нарушения (от немедленного расторжения договора и отзыва всех доступов до обращения за судебной защитой).

Здесь особенно важно не пытаться написать «сильную» формулировку самостоятельно, скопированную из чужого NDA: конкретные механизмы ответственности (неустойка, штраф, порядок доказывания убытков) сильно зависят от юрисдикции и без юридической проверки могут оказаться либо неисполнимыми, либо, наоборот, неприменимо суровыми и потому оспоримыми в суде. Это ровно тот раздел, где формулировку должен предложить или проверить юрист — самостоятельно вписанная цифра штрафа без понимания местной практики может не иметь никакой реальной силы.

NDA — это бумага, а не техническая защита

Практический совет, который легко упустить за юридическими формулировками: даже самый аккуратно составленный NDA не мешает утечке произойти технически — он лишь даёт основание для претензии после того, как она уже случилась. Поэтому NDA имеет смысл сочетать с техническими мерами, а не полагаться на него как на единственный слой защиты.

На практике это означает: подрядчику стоит выдавать не общий root-пароль от сервера, а отдельную ограниченную учётную запись под конкретную задачу — так, как это описано в статье про то, как раздать доступ команде без выдачи root — с правами ровно на то, что нужно для работ, и с личным SSH-ключом, а не общим паролем. По завершении работ такой доступ стоит отзывать сразу, а не «когда вспомните» — удалить ключ из authorized_keys, отключить учётную запись, сменить пароли к сервисам, до которых у подрядчика был доступ. Если подрядчик привлекается не разово, а регулярно, стоит с самого начала формализовать требования к безопасности не только в NDA, но и в самом техническом задании — какой стек, какие ограничения по доступу, какие требования к бэкапам и документации нужно оговорить до начала работ, разобрано в статье как составить ТЗ на настройку сервера для фрилансера.

Сочетание работает так: техническая мера ограничивает, что подрядчик физически может сделать и как быстро вы можете это прекратить, а NDA описывает, что он не имеет права делать с тем, к чему у него был доступ, и что будет, если он это правило нарушит. Одно без другого — половина защиты.

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