Доступ подрядчика к репозиторию: публичный вход или путь через VPN?

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

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

Два входа, две разные границы

Публично доступный сервис репозитория всё равно требует аутентификации HTTPS или SSH и авторизации приложения. Публичная доступность не означает анонимную читаемость. Цена — это слушатель, который нужно поддерживать, отслеживать и обновлять.

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

Сравнивайте разрешённые пути, а не ярлыки. В любом случае сохраняйте аутентификацию приложения и обычную проверку идентичности сервера.

Роли в репозитории — это единица разрешения

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

Перечислите каждую операцию, которая действительно нужна проекту. Доступ через браузер и транспорт Git могут использовать разные учётные данные или слушателей. Автоматизированные сборки, загрузки пакетов и webhook могут работать как отдельные личности со своими путями доставки, и VPN на ноутбуке их не связывает.

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

Учётные данные, которые живут дольше человека

Отключение — это место, где доступ к репозиторию и сетевой доступ снова расходятся. Удалите авторизацию репозитория и право VPN через их владельцев, затем проверьте личные токены, ключи SSH, учётные данные автоматизации и активные сеансы. Ключ развёртывания — классический выживший: он может сохранить настроенный доступ на чтение или запись после ухода человека из организации. Удаление из списка участников — не полное отключение.

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

Проверьте операцию, отказ и отключение

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

Сохраните код и записи проверок, но не позволяйте забытому доступу стать планом восстановления. Письменный список личностей, ролей и сроков действия — это то, что делает следующий запрос подрядчика повторяемым процессом.