Versionskontrollprogramvara som Git har varit en enorm fördel för mjukvaruutvecklingsbranschen. Genom att låta utvecklare enkelt genomföra, dela och be om feedback på versionsändringar i kod har Git och stödjande tjänster som GitHub snabbt ökat i popularitet. Både individer, startups och företag har anammat GitHub som sitt förstahandsval av interna källkodshanteringsdatabaser.
Den här artikeln går igenom några säkerhetstips för GitHub, inklusive allt du behöver veta för att upprätthålla efterlevnaden inom GitHub.
Precis som alla andra tjänster i en uppkopplad företagsmiljö presenterar GitHub och Git-arbetsflödet sina egna säkerhets- och efterlevnadsutmaningar som måste hanteras genom att följa GitHubs säkerhetspraxis och hanteras av organisationens efterlevnadsteam.
Som en hanterad tjänst erbjuder GitHub många alternativ som kan hjälpa dig att upprätthålla efterlevnaden av nödvändiga standarder, men det är fortfarande viktigt att utvärdera kraven i de efterlevnadsprogram som din organisation ansvarar för och säkerställa korrekt användning och övervakning av dessa kontroller.
I den här sammanfattningen delar vi med oss av några bästa praxis för säkerhet på GitHub, inklusive sex efterlevnadsproblem för ingenjörsteam som arbetar i GitHub, och hur man hanterar dem.
Utvärdering av GitHubs efterlevnadskrav
Regelefterlevnadsprogram har väldigt olika krav beroende på målbransch och data som hanteras. För att sammanfatta dessa krav till en hanterbar lista kan det vara bra att skapa en kontrollmatris som består av en övergripande mängd krav. Till exempel kan du behöva följa både Payment Card Industry (PCI) och HIPAA-lagen om bärbarhet och ansvarsskyldighet för sjukförsäkring efterlevnadsprogram, som hanterar olika delar av din databehandlingsstrategi, men överlappar varandra på andra områden. Denna matris av kontroller kan sedan hjälpa dig när du utvärderar och implementerar de säkerhetsalternativ som erbjuds av GitHub.
Generellt sett fokuserar de flesta efterlevnadsprogram på flera nyckelområden: datakategorisering, åtkomstkontroll, behörigheter, granskning och åtkomstgranskning, källkodsintegritet samt säkerhetskopierings- och återställningsprocesser. Genom noggrann implementering av GitHubs funktioner, implementering av tredjepartsverktyg vid behov och regelbundna granskningar kan komplexiteten i dessa efterlevnadskrav minskas.
Bästa säkerhetstips för GitHub: Dataplacering
När du bestämmer dig för att integrera GitHub i din organisation är ett av de viktigaste tidiga efterlevnadsbesluten huruvida du ska använda GitHubs hostade SaaS-tjänst eller att självhosta GitHub med GitHubs Enterprise-alternativ. Faktorer som väger in i detta beslut inkluderar dina drifts- och drifttidskrav, interna supportkriterier och många andra som går utöver omfattningen av den här artikeln. Ur ett efterlevnadsperspektiv är det viktigt att avgöra om något specifikt regelkrav förbjuder användningen av GitHubs hostade alternativ.
Denna undersökning kommer att fokusera starkt på konceptet datakategorisering – klassificeringen av data som din organisation planerar att lagra i GitHub. I de flesta fall kommer detta att inkludera källkod, konfigurationsdata, infrastrukturdokumentation och diagram samt annan känslig data. Beroende på ditt användningsfall kan det också inkludera kunddata, men det är osannolikt att det inkluderar data som kundfaktureringsinformation, hälsojournaler eller andra skyddade dataklasser.
Bästa praxis för säkerhet i GitHub: Åtkomstkontroll och användarhantering
Efterlevnadskrav tenderar att vara mycket specifika kring hur tjänster nås, vem som har åtkomst till dem, hur åtkomsten hanteras och hur den kan återkallas vid behov. Var och en av dessa problem kan åtgärdas direkt med hjälp av olika inställningar som är tillgängliga för GitHub-användare. Prenumeranter på GitHubs Enterprise-planer kan implementera Single Sign-On (SSO)-autentisering med hjälp av SAML-kompatibla identitetsleverantörer. Det här alternativet gör att en organisations åtkomst till GitHub kan hanteras med hjälp av befintliga leverantörer snarare än att implementeras direkt i GitHub med ytterligare en kombination av användarnamn och lösenord att komma ihåg (eller förlora!).
Att dirigera användarhantering till en extern identitetstjänst tar bort en betydande del av de regelbundna åtkomstgranskningar som behöver utföras. Till exempel kan en majoritet av SOC II:s kvartalsvisa användaråtkomstgranskningar delegeras till en federerad identitetsleverantör, snarare än till teamet som hanterar GitHub. Om SSO inte används kan dessa kontroller bli en tidskrävande uppgift att manuellt granska hundratals eller till och med tusentals användare i GitHub-organisationen.
Om användarhantering sker direkt i GitHub bör tvåfaktorsautentisering (2FA) tillämpas på organisationsnivå. Detta kan göras via GitHub-organisationens inställningssidor och säkerställer att alla användare som har åtkomst till GitHub-organisationen använder 2FA när de loggar in på kontot.
En annan företagsfunktion som kan förbättra säkerheten och minska omfattningen av åtkomstgranskningar för efterlevnad är IP-adressbegränsningGitHub Enterprise låter även organisationer ladda upp en lista med IP-adresser, till exempel ett kontor eller VPN utgående adresser, som GitHub använder för att begränsa åtkomsten till GitHub-organisationen och dess tillhörande databaser. Även om detta inte är en tillräcklig kontroll i sig, kan det avsevärt minska attackytan om en GitHub-användares inloggningsuppgifter äventyras.
Även om det inte är ett kärnkrav i de flesta efterlevnadsprogram, kan användningen av grupper för att hantera användaråtkomst avsevärt minska bördan av åtkomsthantering och granskning. Tänk dig komplexiteten i att validera åtkomst till hundratals koddatabaser om användare läggs till direkt som bidragsgivare snarare än till grupper som bidragsgivare. Även om GitHub stöder hantering av användare via team (GitHubs terminologi för gruppmedlemskap), finns det inget enkelt sätt att genomdriva åtkomst via team snarare än direkt åtkomst som användare. Detta är en viktig kontroll att validera under de kvartalsvisa åtkomstgranskningarna eller till och med att automatisera med hjälp av GitHubs API:er.
Bästa praxis för säkerhet i GitHub: Rollbaserad åtkomstkontroll
GitHub har ett inbyggt system för rollbaserad åtkomstkontroll (RBAC) som säkerställer detaljerad åtkomst till arkiv och inställningar. När användare läggs till i organisationen kan de antingen vara ägare eller medlemmar. Ägare är administratörer; de har fullständig åtkomst till organisationen, dess inställningar, andra användare och källkod. Antalet ägare bör hållas till ett absolut minimum, men se till att minst en ägare alltid är tillgänglig för att hantera brådskande inställningsändringar eller andra kritiska aktiviteter. Slutligen bör en användares medlemskap i en organisation hållas privat för att undvika social engineering-attacker där en angripare riktar in sig på specifika användare baserat på kända organisationsassociationer.
Medlemmar kan läggas till direkt i arkiven med en av fem roller, från "läs" (en grundläggande skrivskyddad roll) till "administratör" (full åtkomst). Istället för att lägga till dessa medlemmar direkt i arkivet kan de bjudas in till ett team istället. Detta team kan sedan ges samma roller till arkivet. Detta är ett mycket enklare sätt att upprätthålla användaråtkomst och hjälper till att minska oavsiktlig överprovisionering.
Bästa praxis för säkerhet på GitHub: Åtkomst från tredje part
Användare är inte de enda enheterna som kan ges åtkomst till GitHub. GitHub-applikationer från tredje part, OAuth-integrationer, webhooks och API-integrationer kan alla ges olika nivåer av åtkomst till GitHubs inställningar och källkod för arkivet. Det är avgörande att denna åtkomst är begränsad, noggrant avgränsad och granskad regelbundet. Kom ihåg att dessa applikationer inte ägs eller underhålls av GitHub, så din organisation bär fullt ansvar för deras användning.
Bästa praxis för säkerhet på GitHub: Granskning
En central del av de flesta efterlevnadsprogram är loggning av all åtkomst till system. Inom katastrofåterställning och säkerhet obduktionerAtt veta vem som åtkom till ett system, varifrån förfrågningarna kom och vilka data som åtkom är viktiga krav för att lyckas återställa efter en incident. Lyckligtvis stöder GitHub detaljerad granskningsloggning som inkluderar tidsstämplar, IP-adresser, användarnamn och åtkomna resurser. Dessa loggar kan nås av organisationsägare från GitHub-konsolen.
Bästa praxis för säkerhet på GitHub: Kodsäkerhet
Källkod är kanske den känsligaste informationen som din organisation lagrar i GitHub. Förlust av kontroll över denna kod kan leda till väl utformade säkerhetsintrångsförsök och exponering av ditt företags immateriella rättigheter. GitHub levereras med robusta åtkomstkontrollinställningar för arkiv, men det är fortfarande nödvändigt för dina team att implementera dessa inställningar korrekt och rutinmässigt granska deras konfiguration. Varje arkiv kan antingen vara offentligt eller privat. I de flesta företagsmiljöer bör standardinställningen för alla arkiv vara "privat". GitHub tillhandahåller ett val för att säkerställa att alla nyskapade arkiv som standard är privata, vilket bör aktiveras på organisationsnivå.
GitHub erbjuder flera ytterligare funktioner som hjälper till att säkerställa integriteten hos dina källkodsförråd. Signerade commits, en funktion som gör det möjligt för utvecklare att kryptografiskt bevisa kodförfattarskap, kan ge större säkerhet för att koden som skickas in kommer från de avsedda utvecklarna. GitHub stöder också godkänna kända domäner som bidragsgivare till organisationens kodbaserDetta hjälper till att förhindra att illvilliga användare med liknande domäner av misstag godkänns att skicka in kod. Slutligen, grenskydd kan aktiveras för att kräva att utvecklare flyttar sin kod genom godkända arbetsflöden, till exempel pull requests, istället för att skicka den direkt till uppströmsgrenen.
Genom en rad förvärv har GitHub också börjat erbjuda beroende- och säkerhetsskanning för repositorier, för att säkerställa att kritiska säkerhetsrisker upptäcks och åtgärdas. Vissa problem med beroendeversioner kan till och med åtgärdas automatiskt med GitHubs automatiserade verktyg. Dependabot.
Bästa säkerhetstips för GitHub: Säkerhetskopiering och återställning
Som tjänsteleverantör är GitHub generellt ansvarigt för säkerhetskopiering av sina system och användardata. Många efterlevnadsprogram kräver dock att användare av tredjepartsverktyg som GitHub också har ett delat ansvar för att implementera säkerhetskopierings- och återställningsprocesser för sina data. Med andra ord, även om det är osannolikt att GitHub permanent skulle förlora dina data, har du fortfarande en skyldighet att visa att du har säkerhetskopior som kan återställas i händelse av en nödsituation eller säkerhetssituation. Läs mer om den delade ansvarsmodellen för SaaS-data. här..
För att helt följa myndighetskrav måste dessa säkerhetskopior göras med jämna mellanrum, lagras utanför anläggningen på olika system och hårdvara, och testas regelbundet som en del av övningar för katastrofåterställning. Olika efterlevnadsprogram har... varierande acceptabla tidsramar och förfaranden, men behovet av en pålitlig säkerhetskopieringslösning är konsekvent. Tredjepartsleverantörer, som till exempel Rewind, kan minska mycket av komplexiteten i den här processen och hjälpa dig att följa 3-2-1 backup-regel.
Slutsats: GitHub och efterlevnad
Även om det kan verka skrämmande att anpassa din organisations efterlevnadskrav till din användning av GitHub, finns det många inbyggda och tredjepartsalternativ som avsevärt kan minska komplexiteten, förbättra din säkerhetsställning och säkerställa att dina data förblir säkra och uppfyller dina kunders förväntningar. Noggrant val av dessa kontroller är ett bra första steg, men kontinuerlig granskning och regelbundna åtkomstrevisioner är avgörande för fortsatt framgång.
