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

Підряднику потрібен один приватний репозиторій для обмеженого проєкту, і запит надходить або як «зробіть репозиторій публічним», або як «дайте їм доступ через VPN». Обидві відповіді оминають справжнє питання. Авторизація репозиторію та мережевий вхід — це різні шари, і важливим є той дозвіл, який дає цій людині читати або робити push саме в цей один репозиторій. Усе інше в будь-якому наборі — додатковий ризик. Спершу спроєктуйте шар авторизації, потім виріште, скільки мінімум мережевого шляху йому потрібно.

Показовий проєкт робить це конкретним: один зовнішній розробник, один репозиторій, жодних продакшн-хостів, жодного інтерфейсу адміністрування. Тримайте цей обсяг незмінним, поки порівнюєте входи.

Два входи, дві різні межі

Публічно доступний сервіс репозиторію все одно вимагає автентифікації HTTPS або SSH і авторизації застосунку. Публічна доступність не означає анонімної читабельності. Ціна — це слухач, який потрібно підтримувати, відстежувати й оновлювати.

Вхід через VPN може тримати цього слухача поза публічним шляхом, але широкий обліковий запис VPN може відкрити сторонні сервіси. Залишене публічне ім'я хоста, слухач SSH або забута родина адрес можуть зруйнувати межу «лише VPN», яку ви думали, що маєте. Тому проєкт «лише VPN» потребує інвентаризації слухачів, а не лише правила брандмауера.

Порівнюйте дозволені шляхи, а не ярлики. У будь-якому разі зберігайте автентифікацію застосунку та звичайну перевірку ідентичності сервера.

Ролі в репозиторії — це одиниця дозволу

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

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

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

Облікові дані, які живуть довше за людину

Відключення — це місце, де доступ до репозиторію і мережевий доступ знову розходяться. Видаліть авторизацію репозиторію та право VPN через їхніх власників, потім перевірте особисті токени, ключі SSH, облікові дані автоматизації та активні сеанси. Ключ розгортання — класичний вижилий: він може зберегти налаштований доступ на читання або запис після того, як людина залишає організацію. Видалення зі списку учасників — не повне відключення.

Проінвентаризуйте машинні облікові дані за власником і призначенням до завершення проєкту, а не після. Токен, створений для тижневої збірки, може пережити проєкт на рік, якщо ніхто не записав, навіщо він існує.

Перевірте операцію, відмову та відключення

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

Зберігайте код і записи перевірок, але не дозволяйте забутому доступу стати планом відновлення. Письмовий список ідентичностей, ролей і термінів дії — це те, що робить наступний запит підрядника повторюваним процесом.