NetBird для подрядчиков: доступ к одному сервису на ограниченный срок

У работы подрядчика есть дата окончания, и в этой статье она важнее всего остального: пятница. Специалист настраивает отчёты в одной административной панели, в пятницу сдаёт задачу, а в понедельник его ноутбук уже не должен иметь к вашей сети никакого отношения. Проблема в том, что «не должен» само по себе не происходит. Доступы живут дольше проектов по той же причине, по которой старые коробки живут на антресолях: никто не помнит, кто их туда поставил, и убирать страшновато.

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

Сначала описываем комнату, а не здание

Возьмём условный сценарий. В офисной подсети 10.20.0.0/24 живёт десяток машин: файловое хранилище, база данных бухгалтерии, пара принтеров, тестовый стенд и сервер с административной панелью отчётов. Панель слушает на адресе 10.20.0.15, порт 8443. Подрядчику нужна только она. Цифры здесь иллюстративные; смысл в том, что из всей подсети ему нужен ровно один адрес и ровно один порт.

Самый короткий путь — завести в NetBird сеть на всю 10.20.0.0/24 и выдать подрядчику доступ к ней. Работать будет с первого раза, и именно поэтому это плохое решение: вместе с панелью подрядчик получит сетевую видимость хранилища, базы и стенда. Даже если у них свои пароли, сам факт, что они доступны для сканирования и попыток входа с ноутбука постороннего человека, уже лишний риск.

В документации по сетям NetBird устройство ресурсов описано так: Network объединяет ресурсы, routing peers и политики доступа, а ресурсом может быть один IP, CIDR или домен. Значит, вместо подсети можно описать ровно один хост. Для нашего примера ресурс — это адрес 10.20.0.15, а не вся 10.20.0.0/24. Эта разница решает больше, чем любые дальнейшие настройки: то, что не описано как ресурс, подрядчик через эту сеть просто не получит.

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

Хост или домен

Ресурс можно описать адресом или доменным именем. Если панель живёт по адресу, который не меняется, достаточно IP. Если у неё есть внутреннее имя и за ним могут смениться адреса, удобнее домен. Но для подрядчика есть своя тонкость: доменное имя нередко указывает на несколько сервисов за одним балансировщиком, и тогда «один ресурс» окажется шире, чем кажется. Прежде чем записать домен, выясните, что именно за ним скрывается. Для разовой работы с одной панелью голый адрес проще и нагляднее: его легко проверить глазами, и он не меняет смысл от чужой правки DNS.

Отдельный вопрос — где разместить routing peer. Если панель стоит на отдельной машине, routing peer можно развернуть на самой этой машине или рядом с ней. В небольших схемах эту роль часто отдают небольшому VPS: он принимает подключения NetBird и пропускает трафик к панели. Если у вас уже есть VPS MAATRIX с root-доступом, под такой узел можно взять начальный тариф Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и посмотреть, как он ведёт себя на реальной нагрузке одного пользователя. Это отправная точка для теста, а не обещание ёмкости: один подрядчик с одной веб-панелью трафика создаёт немного, но реальную нагрузку лучше измерить, а не предполагать. Если панели нужен отчёт на сотни мегабайт, картина будет другой.

Человек и ноутбук — это не одно и то же

Теперь о том, кто подключается. В голове администратора подрядчик — один человек, «Игорь, который настраивает отчёты». В системе же есть как минимум две сущности: учётная запись человека и подключённое устройство. Устройство — ноутбук, который может завтра смениться, а может оказаться общим с другими проектами подрядчика. Игорь уйдёт, а ноутбук с установленным клиентом останется в той же группе и с теми же разрешениями.

Из этого следует практическое решение: ни при каких условиях не добавлять подрядчика в рабочие группы сотрудников. Заведите отдельную группу, назовите её понятно — например, contractor-reports-igor или по номеру заявки. Название должно отвечать на три вопроса: кто, зачем и по какой задаче. Через полгода, открыв список групп, вы должны без расследования понять, можно ли её удалять.

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

Если у вас настроена двухфакторная проверка для внешних учётных записей, имеет смысл сделать её обязательной именно для подрядчиков: у них нет вашей корпоративной дисциплины, и второй фактор здесь не бюрократия, а страховка на случай утери ноутбука. Подробнее о том, как это устроено в NetBird и Tailscale, рассказано в материале о двухфакторной аутентификации в Tailscale и Netbird.

Один человек — одна группа — одна задача

Соблазн сделать «общую группу подрядчиков» понятен: удобно, когда все внешние специалисты в одном месте. Но у такой группы есть неприятное свойство: права накапливаются. Сегодня туда добавили Игоря с панелью отчётов, через месяц — Марину с доступом к стенду, и вот уже Игорь, давно закончивший работу, формально имеет доступ к стенду Марины, потому что политика адресована группе. Одна задача — одна группа. Когда задача закрыта, закрывается и группа вместе с политикой.

Из этого есть следствие для именования. Если группа называется по задаче, а не по человеку, то в случае замены исполнителя (например, Игорь заболел, и работу продолжает коллега) вы добавляете нового человека в ту же группу, и права остаются теми же. Это удобно, но проверять надо одно: правда ли, что задача и права по-прежнему совпадают.

Политика: четыре параметра и один подводный камень

Политика в NetBird задаёт источники, назначения, протоколы и порты. Для нашего случая заполнение выглядит так:

Заметьте, что сужение идёт сразу по трём осям: кто, куда и как. Если пропустить протокол или порт, политика станет шире, чем вы рассчитывали: подрядчик сможет стучаться не только на веб-интерфейс, но и на любой другой сервис того же хоста, например на SSH или на отладочный порт. Хост может содержать больше, чем показывает панель в браузере. Узкий порт — это не педантизм, а способ не открыть то, о чём вы забыли.

Разрешения суммируются

Теперь главный подводный камень. В описании политик отмечено, что разрешения суммируются, а широкая Default policy сохраняет общий доступ. Это значит, что узкая политика для подрядчика не вычитает ничего из того, что открыто другими правилами. Если в вашей организации осталась политика по умолчанию, разрешающую всем группам ходить ко всем, то подрядчик в её рамках может получить значительно больше, чем вы описали в своём аккуратном правиле. Узкое правило добавляется к широкому, а не заменяет его.

Это самая частая причина, по которой «ограниченный» доступ оказывается неограниченным. Администратор делает всё правильно: отдельная группа, один ресурс, один порт, — а потом выясняется, что Default policy всё это время работала параллельно. Поэтому прежде чем выдавать доступ, откройте список политик и ответьте на конкретный вопрос: какие из действующих правил в качестве источника или назначения могут захватить группу подрядчика? Если есть политика, где источник — все, а назначение — все, её нужно либо сузить, либо исключить из неё группу подрядчика, либо заменить набором точечных правил. Менять общую политику в рабочей сети надо осторожно и вне рабочего пика, потому что сотрудники привыкли к её широте. Но выдавать внешнему человеку доступ, пока она действует, значит полагаться на удачу.

Практическая проверка занимает пять минут. Зарегистрируйте тестовое устройство, положите его только в группу подрядчика и убедитесь, что панель на 10.20.0.15:8443 открывается, а соседний адрес, например 10.20.0.20, и соседний порт того же хоста не отвечают. Если отвечают, где-то есть лишнее правило. Тест нужно повторить после любого изменения политик, а не один раз при запуске.

Вторая дверь: учётная запись самой панели

Сеть — это только одна из двух дверей. Допустим, подрядчик попал на 10.20.0.15:8443. Теперь на экране форма входа в саму панель. И вот здесь начинается уровень прав приложения, который сеть никак не регулирует. NetBird решает, дойдёт ли пакет до порта; что человек увидит после входа, решает панель.

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

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

Задайте учётной записи понятное имя, по которому через месяц видно, что она временная: например, contractor-igor-reports. Если панель позволяет указать срок действия учётной записи или принудительную смену пароля, используйте это, но сверьтесь с возможностями конкретного продукта: у разных панелей эти функции разные, и на них нельзя полагаться заранее. Для плана ниже мы будем считать, что автоматического срока нет, и отключать учётную запись будем руками.

Что на самом деле означает «на ограниченный срок»

Пришло время честно ответить на вопрос, с которого мы начали. Можно ли в NetBird сказать «доступ действует до пятницы, 18:00» и больше об этом не думать? В описании политик есть переключатель Active, который отключает политику, и возможность её удалить. Это ручные действия. Встроенного поля «действует до даты» для политики в этих материалах не описано, поэтому закладываться на автоматическое истечение нельзя: считайте, что закрывать доступ будет человек.

Есть и вторая ловушка, на которую часто попадаются. Для регистрации устройств в NetBird используются setup key, и у ключа может быть срок действия. Но срок ключа — это срок, в течение которого им можно зарегистрировать новое устройство. Он не отзывает уже зарегистрированное устройство. Если Игорь воспользовался ключом в среду, а ключ истёк в четверг, ноутбук Игоря остаётся подключённым и по-прежнему ходит по тем политикам, которые разрешены его группе. Короткий срок ключа полезен как защита от того, что ключ потом перешлют третьему лицу, но к завершению работ он отношения не имеет.

Значит, срок обеспечивается не настройкой, а процедурой. Она состоит из пяти пунктов, и каждый должен иметь исполнителя и дату:

1. Владелец доступа. Один конкретный человек у вас, который отвечает за то, что доступ будет закрыт. Не «ИТ-отдел» и не «мы», а имя. Обычно это тот, кто принимает работу.
2. Дата и время закрытия. Не «в конце недели», а пятница, 18:00. Запишите её в календарь владельцу как событие с напоминанием и в описание группы или политики, если интерфейс позволяет оставить описание.
3. Действие в сети. В назначенное время отключить политику переключателем Active. Если работа точно закончена и возвращаться к ней не планируется, затем удалить политику, а устройство подрядчика убрать из группы. Члены группы определяют фактические права, поэтому пустая группа без политики — надёжнее, чем группа с «выключенным» правом.
4. Действие в панели. Отключить учётную запись contractor-igor-reports или заблокировать её средствами самой панели; если нужно сохранить историю действий для разбора, удаление лучше отложить, а вот возможность входа закрыть сразу.
5. Проверка. Убедиться, что вход действительно невозможен, как описано в следующем разделе, и отметить это в задаче.

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

Что если работа затянется? Это нормальная ситуация, и план должен её допускать. Продление — это тоже явное действие: владелец записывает новую дату и продолжает с ней. Сломанным считается не продление, а молчаливое продолжение доступа после даты, никем не подтверждённое. Хорошая привычка: любое продление фиксируется в той же задаче, что и выдача, с новой датой закрытия.

Проверка после закрытия: что именно пробовать

Когда пятница пришла и действия выполнены, остаётся самое важное — убедиться, что они сработали. Закрытый доступ, который не проверяли, ничем не отличается от доступа, который закрыли по ошибке не там. Проверять нужно с двух сторон.

Со стороны подрядчика (лучше попросить его самого или воспользоваться тестовым устройством из его группы, если оно ещё в ней):

• открыть https://10.20.0.15:8443 в браузере: страница не должна загружаться; ожидаемый результат — таймаут или отказ соединения, а не форма входа;
• если страница всё же открылась, попробовать войти под учётной записью подрядчика: вход должен быть отклонён или заблокирован;
• повторить обращение к соседним адресам и портам, которые и раньше были недоступны, чтобы убедиться, что не появилось ничего нового.

Со стороны администратора:

• в списке политик найти правило подрядчика и убедиться, что оно выключено переключателем Active или удалено;
• проверить состав группы подрядчика: устройств быть не должно, либо должны остаться только те, что вы сознательно оставили;
• просмотреть остальные политики и убедиться, что ни одна по-прежнему не охватывает эту группу широким правилом, в том числе Default policy;
• в самой панели проверить, что учётная запись отключена, и что активных сессий этого пользователя нет, если панель показывает сессии.

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

Если проверка нашла дыру, например, страница всё-таки открывается, не торопитесь исправлять только это место. Найдите причину: чаще всего это либо та самая широкая политика, либо устройство, забытое в другой группе. Исправьте причину и повторите проверку от начала. Дыра, найденная в день закрытия, — это успех процедуры, а не её провал: именно для этого проверка и нужна.

Чем отличается правильный доступ от «пока сойдёт»

Сравним два способа выдать доступ в одной и той же ситуации — одна панель, один подрядчик, одна неделя.

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

Когда у подрядчика несколько задач

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

Это же правило работает для нескольких подрядчиков на одной панели. Две группы, две политики, две даты. На первый взгляд это дублирование, но каждая такая запись живёт и умирает сама по себе, и вы никогда не окажетесь в ситуации, когда нельзя убрать доступ одному человеку, потому что он общий с другим.

Где всё это жить: немного о ресурсах

Routing peer, через который подрядчик дотягивается до панели, — это обычный узел, и к нему стоит относиться как к рабочему компоненту, а не как к временному костылю. Если вы выносите его на VPS, пригодятся root-доступ для установки клиента и настройки сетевых параметров, а также возможность быстро создать машину под задачу и убрать после. В публичном предложении MAATRIX указаны локации UK, US, RU и FR, оплата картой РФ и через СБП, а новый VPS создаётся автоматически через пару минут после оплаты, так что узел под разовую задачу можно поднять быстро. Выбирать локацию стоит по близости к панели и пользователям: чем меньше между ними лишних переходов, тем отзывчивее будет интерфейс.

По ресурсам начните с малого. Для узла, который проксирует веб-панель для одного человека, тариф Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) — разумная точка для пробного запуска; если панель отдаёт тяжёлые выгрузки или подключаются сразу несколько специалистов, переходите к Uab (2 vCPU, 4 ГБ, 80 ГБ) или выше. Но это стартовые значения для испытания на вашем трафике, а не гарантия того, сколько пользователей выдержит узел. Посмотрите загрузку процессора и канала в первый рабочий день подрядчика, и решение о размере станет основано на цифрах.

Если же панель, к которой нужен доступ, вы только планируете развернуть — скажем, для внешнего подрядчика отдельно от рабочей инфраструктуры, — в каталоге MAATRIX предлагаются n8n и Nextcloud с установкой; наличие и операционная система уточняются в форме заказа. Отдельная машина для сервиса, которую подрядчик увидит через NetBird, — удобный способ вообще не пускать его рядом с остальной подсетью: описывать приходится один хост, и он по определению единственный.

Пятница наступила

В пятницу в 17:40 Игорь пишет, что отчёты готовы и выгружены. Владелец доступа принимает результат, открывает календарь, где стоит напоминание на 18:00, и начинает с сети. Переключатель Active у политики подрядчика уходит в выключенное положение. Устройство Игоря убрано из группы contractor-reports-igor, сама группа пуста. Затем владелец заходит в панель и отключает учётную запись contractor-igor-reports.

Теперь проверка. Игорь по просьбе открывает https://10.20.0.15:8443 со своего ноутбука: страница не грузится. Тест с запасным устройством из пустой группы даёт то же самое. В списке политик владелец ещё раз просматривает широкие правила и убеждается, что ни одно не захватывает группу подрядчика. В панели учётная запись отмечена как отключённая, активных сессий нет. В задаче появляется короткая запись: сеть закрыта, учётная запись отключена, вход проверен, дата и время.

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