Достъп на изпълнител до хранилище: публичен вход или път през VPN?

Изпълнител се нуждае от едно частно хранилище за ограничен проект и заявката идва като «направете хранилището публично» или «дайте им достъп през VPN». И двата отговора пропускат истинския въпрос. Оторизацията на хранилището и мрежовият вход са отделни слоеве и разрешението, което има значение, е това, което позволява на този човек да чете или да push към това едно хранилище. Всичко останало в който и да е пакет е допълнителен риск. Проектирайте първо слоя за оторизация, после решете колко малко мрежов път му е нужен.

Един пример прави това конкретно: един външен разработчик, едно хранилище, без продукционни хостове, без административен интерфейс. Дръжте този обхват фиксиран, докато сравнявате входовете.

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

Публично достъпна услуга за хранилище все още налага HTTPS или SSH удостоверяване и оторизация на приложението. Публичната достъпност не означава анонимна четимост. Цената е слушател, който трябва да поддържате, наблюдавате и обновявате.

VPN входът може да държи този слушател извън публичния път, но широк VPN акаунт може да изложи несвързани услуги. Остаряло публично име на хост, SSH слушател или семейство адреси, което сте забравили, могат да провалят границата само през VPN, която сте мислили, че имате. Затова дизайнът само през VPN се нуждае от инвентар на слушателите, а не само от правило на защитната стена.

Сравнявайте разрешените пътища, не етикетите. Във всеки случай запазете удостоверяването на приложението и нормалната проверка на идентичността на сървъра.

Ролите в хранилището са единицата за разрешение

Дайте на изпълнителя индивидуална идентичност с най-малката роля, която изпълнява задачата. Преглед, push, поддръжка и администриране са различни роли и група, която дава всеки вътрешен проект, не е същото като достъп до едно хранилище. Проверете действителните имена на ролите във вашата платформа, вместо да предполагате, че име на група съответства на една роля.

Избройте всяка операция, която ангажиментът наистина изисква. Достъпът през браузър и Git транспорта може да използват различни удостоверения или слушатели. Автоматизираните билдове, изтеглянията на пакети и webhook могат да работят като отделни идентичности със собствени пътища за доставка и VPN на лаптопа не ги свързва.

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

Удостоверения, които живеят по-дълго от човека

Извеждането от организацията е мястото, където достъпът до хранилището и мрежовият достъп отново се разделят. Премахнете оторизацията за хранилището и правото за VPN чрез съответните им собственици, после проверете личните токени, SSH ключовете, удостоверенията за автоматизация и активните сесии. Ключът за разгръщане е класическият оцелял: той може да запази конфигурирания си достъп за четене или запис, след като човекът напусне организацията. Премахването от списък с членове не е пълно извеждане.

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

Проверете операцията, отказа и извеждането

Преди предаването тествайте три неща: разрешената операция с хранилището успява, несвързано хранилище се отказва и оттеглената идентичност се проваля. Ако дизайнът е само през VPN, потвърдете, че старият директен публичен маршрут вече не може да извърши операцията.

Пазете кода и записите от прегледи, но не позволявайте забравеният достъп да стане план за възстановяване. Писменият списък с идентичности, роли и дати на изтичане е това, което прави следващата заявка за изпълнител повтаряем процес.