A vállalkozó hozzáférése a tárolóhoz: nyilvános belépés vagy VPN-útvonal?

Egy vállalkozónak egy privát tárolóra van szüksége egy korlátozott projekthez, és a kérés vagy úgy érkezik, hogy «tegye nyilvánossá a tárolót», vagy úgy, hogy «adjon nekik VPN-hozzáférést». Mindkét válasz megkerüli az igazi kérdést. A tároló engedélyezése és a hálózati belépés külön rétegek, és az a jogosultság számít, amely lehetővé teszi, hogy az a személy olvasson vagy pusholjon ebbe az egy tárolóba. Minden más bármelyik csomagban további kockázat. Először tervezze meg az engedélyezési réteget, aztán döntse el, milyen kevés hálózati útvonalra van szüksége.

Egy szemléltető megbízás konkréttá teszi: egy külső fejlesztő, egy tároló, nincs termelési gazdagép, nincs adminisztrációs felület. Tartsa ezt a hatókört rögzítve, miközben összehasonlítja a belépéseket.

Két belépés, két különböző határ

A nyilvánosan elérhető tárolószolgáltatás továbbra is kikényszeríti a HTTPS vagy SSH hitelesítést és az alkalmazásengedélyezést. A nyilvános elérhetőség nem jelent névtelen olvashatóságot. Az ár egy figyelő, amelyet karban kell tartania, figyelnie és javítania kell.

A VPN-belépés távol tarthatja ezt a figyelőt a nyilvános útvonaltól, de egy széles VPN-fiók kapcsolódó szolgáltatásokat tehet ki. Egy hátrahagyott nyilvános gazdagépnév, egy SSH-figyelő vagy egy elfelejtett címcsalád megtörheti a csak-VPN határt, amelyről azt hitte, hogy van. Ezért a csak-VPN tervezéshez figyelők leltára kell, nem csak egy tűzfal-szabály.

Az engedélyezett útvonalakat hasonlítsa össze, nem a címkéket. Minden esetben tartsa meg az alkalmazáshitelesítést és a szokásos kiszolgálóidentitás-ellenőrzést.

A tároló szerepei a jogosultság egységei

Adjon a vállalkozónak egyéni identitást a legkisebb szereppel, amely a feladatot elvégzi. A megtekintés, a push, a karbantartás és az adminisztráció különböző szerepek, és egy csoport, amely minden belső projektet megad, nem ugyanaz, mint az egy tárolóhoz való hozzáférés. Ellenőrizze a tényleges szerepneveket a platformján, ahelyett hogy feltételezné, hogy egy csoportnév egy szerephez rendelődik.

Sorolja fel minden műveletet, amelyre a megbízásnak valóban szüksége van. A böngészős hozzáférés és a Git-szállítás különböző hitelesítő adatokat vagy figyelőket használhat. Az automatizált buildek, a csomagletöltések és a webhookok külön identitásként futhatnak saját szállítási útvonalakkal, és a laptopon lévő VPN nem köti össze őket.

A tároló tartalmának védelme külön munka. A belépési útvonal megváltoztatása nem távolít el egy már az előzményekben lévő titkot, nem korlátoz egy engedélyezett klónt, és nem biztosít egy közreműködő munkaállomását.

Hitelesítő adatok, amelyek túlélik a személyt

A kiléptetés az a pont, ahol a tárolóhozzáférés és a hálózati hozzáférés ismét szétválik. Távolítsa el a tároló engedélyezését és a VPN-jogosultságot a megfelelő tulajdonosokon keresztül, majd ellenőrizze a személyes tokeneket, SSH-kulcsokat, automatizálási hitelesítő adatokat és az aktív munkameneteket. A telepítési kulcs a klasszikus túlélő: megtarthatja a beállított olvasási vagy írási hozzáférést, miután a személy elhagyja a szervezetet. A tagsági listáról való eltávolítás nem teljes kiléptetés.

A megbízás vége előtt leltározza a gépi hitelesítő adatokat tulajdonos és cél szerint, nem utána. Egy egyhetes buildhez létrehozott token egy évvel túlélheti a projektet, ha senki nem írta le, miért létezik.

Ellenőrizze a műveletet, a megtagadást és a kiléptetést

Átadás előtt teszteljen három dolgot: az engedélyezett tárolóművelet sikerül, egy kapcsolódó tároló megtagadásra kerül, és a kivont identitás meghiúsul. Ha a tervezés csak-VPN, erősítse meg, hogy a régi közvetlen nyilvános útvonal már nem tudja végrehajtani a műveletet.

Őrizze meg a kódot és az ellenőrzési nyilvántartásokat, de ne engedje, hogy az elfelejtett hozzáférés legyen a helyreállítási terv. Az identitások, szerepek és lejárati dátumok írott listája az, ami a következő vállalkozói kérést megismételhető folyamattá teszi.