Přístup dodavatele k repozitáři: veřejný vstup, nebo cesta přes VPN?

Dodavatel potřebuje jeden soukromý repozitář pro omezený projekt a žádost přichází buď jako «udělejte repozitář veřejným», nebo «dejte jim přístup přes VPN». Obě odpovědi obcházejí skutečnou otázku. Autorizace repozitáře a síťový vstup jsou oddělené vrstvy a oprávnění, na kterém záleží, je to, které této osobě umožní číst nebo pushovat do tohoto jednoho repozitáře. Vše ostatní v kterémkoli balíku je riziko navíc. Nejprve navrhněte autorizační vrstvu, potom rozhodněte, jak málo síťové cesty potřebuje.

Ilustrativní zakázka to zkonkrétní: jeden externí vývojář, jeden repozitář, žádné produkční hosty, žádné administrativní rozhraní. Držte tento rozsah pevný, dokud porovnáváte vstupy.

Dva vstupy, dvě různé hranice

Veřejně dostupná služba repozitáře stále vynucuje autentizaci HTTPS nebo SSH a autorizaci aplikace. Veřejná dostupnost neznamená anonymní čitelnost. Cenou je listener, který musíte udržovat, monitorovat a záplatovat.

Vstup přes VPN může tento listener držet mimo veřejnou cestu, ale široký účet VPN může odhalit nesouvisející služby. Zbytkové veřejné jméno hostitele, SSH listener nebo rodina adres, na kterou jste zapomněli, mohou zničit hranici pouze přes VPN, o které jste si mysleli, že ji máte. Proto návrh pouze přes VPN potřebuje inventář listenerů, ne jen pravidlo firewallu.

Porovnávejte povolené cesty, ne štítky. V každém případě ponechte autentizaci aplikace a běžné ověření identity serveru.

Role v repozitáři jsou jednotkou oprávnění

Dejte dodavateli individuální identitu s nejmenší rolí, která úkol dokončí. Prohlížení, pushování, údržba a správa jsou různé role a skupina, která přiděluje každý interní projekt, není totéž jako přístup k jednomu repozitáři. Zkontrolujte skutečné názvy rolí ve své platformě, místo abyste předpokládali, že název skupiny odpovídá jedné roli.

Vyjmenujte každou operaci, kterou zakázka skutečně potřebuje. Přístup z prohlížeče a přenos Git mohou používat různé přihlašovací údaje nebo listenery. Automatizované buildy, stahování balíčků a webhooky mohou běžet jako samostatné identity s vlastními cestami doručení a VPN na notebooku je nepropojí.

Ochrana obsahu repozitáře je samostatná práce. Změna vstupní cesty neodstraní tajemství, které už je v historii, neomezí autorizovaný klon ani nezabezpečí pracovní stanici přispěvatele.

Přihlašovací údaje, které přežijí člověka

Odchod je místo, kde se přístup k repozitáři a síťový přístup znovu rozcházejí. Odstraňte autorizaci repozitáře a nárok na VPN prostřednictvím jejich vlastníků, potom zkontrolujte osobní tokeny, SSH klíče, přihlašovací údaje automatizace a aktivní relace. Deploy klíč je klasický přeživší: může si ponechat nastavený přístup pro čtení nebo zápis poté, co osoba opustí organizaci. Odebrání ze seznamu členů není úplný odchod.

Zinventarizujte strojové přihlašovací údaje podle vlastníka a účelu před koncem zakázky, ne po něm. Token vytvořený pro týdenní build může projekt přežít o rok, pokud nikdo nezapsal, proč existuje.

Ověřte operaci, odmítnutí i odchod

Před předáním otestujte tři věci: povolená operace s repozitářem uspěje, nesouvisející repozitář je odmítnut a vyřazená identita selže. Pokud je návrh pouze přes VPN, potvrďte, že stará přímá veřejná cesta už operaci provést nemůže.

Uchovejte kód i záznamy o revizi, ale nedovolte, aby se zapomenutý přístup stal plánem obnovy. Písemný seznam identit, rolí a dat expirace je to, co dělá z další žádosti dodavatele opakovatelný proces.