Skydda utvecklarmiljön för Nolltillit

  • Artikel

Den här artikeln hjälper dig som utvecklare att skydda din utvecklingsmiljö så att du kan implementera Nolltillit principer (verifiera uttryckligen, använd åtkomst med minsta möjliga behörighet, anta intrång). Den innehåller innehåll från vår e-bok Skydda Enterprise DevOps-miljöer och visar bästa praxis för verktyg, tillägg och integreringar för grensäkerhet och förtroende.

Utvecklarhastigheten förlitar sig på din förmåga att arbeta hur och var du vill maximera affärsresultat. Du vill ha kraftfulla, anpassningsbara datorer med rot- eller administratörsåtkomst. Utvecklarkraven kan dock strida mot efterlevnadsreglerna och behovet av att granska och kontrollera åtkomst och lagring för privata anställdas miljö.

Ohanterade datorer som ansluter till organisationens nätverksutmaningssäkerhetsteam, anskaffning och styrningstavla. Det bästa scenariot med att ge utvecklare standardmiljöer och härdade medarbetarmiljöer skapar förakt på båda sidor. När anställda ansluter var som helst är sårbara Wi-Fi-nätverk en öppen dörr för cyberattacker. Stöld och förlust av maskinvara är viktiga problem.

Sårbarheter omfattar integrering av utvecklingsmiljön. Utvecklingsverktyg som har omfattande utökningsbarhet kan ha oönskade integreringar på sina marknadsplatser. Skadliga tillägg kan äventyra utvecklarverktyg och orsaka företagsomfattande överträdelser.

I diagrammet nedan ser du hur utvecklarmiljön ansluter till DevOps-verktygsmiljön för att påverka Git-grenar. Den breddar miljöytan genom anslutning till tredjepartspaket med öppen källkod och programtillägg. Tillägg presenterar attackvektorer i sårbarheter i beroende- och tilläggsprogram.

Diagrammet illustrerar utvecklarmiljöer och säkerhetshot enligt beskrivningen i föregående e-bok och sammanfattas i relaterade artiklar som är länkade häri.

Att ge DevOps-teammedlemmar flexibilitet och kontroll samtidigt som skadliga attacker förhindras är en grundläggande utmaning för säkerhetskontor. DevOps kan styra utvecklarmiljön med en molnmiljö (se Betrodd start för virtuella Azure-datorer och GitHub Enterprise Cloud Docs) och skydda utvecklarmiljön med containrar (se Dokumentation om GitHub Codespaces).

Dessutom kan utvecklare implementera dessa Nolltillit åtgärder för att skydda utvecklarmiljön:

  • Konfigurera minsta behörighet.
  • Begränsa vem som kan ändra och godkänna kod med grensäkerhet.
  • Anta endast betrodda verktyg, tillägg och integreringar.

Metodtips för minsta möjliga behörighet

Utvecklare tror ofta att de kan fånga skadlig kod, nätfiske och intrång i sina miljöer. Stora hotytor i utvecklarmiljön gör det orealistiskt för utvecklare att upprätthålla allestädes närvarande systemkunskaper. När en organisation upptäcker ett intrång efter en attack komprometterar en utvecklarmiljö som har administratörsåtkomst till alla system, kan dyrbar reparationstid redan ha passerat.

För att åtgärda potentiella åtkomstmöjligheter som gör att hackare riktar in sig på programvaruutvecklarens roll bör du överväga följande Nolltillit bästa praxis för säkerhet med minst privilegier för appar.

  • Implementera lägsta behörighet och just-in-time-åtkomst för DevOps. Se till att gruppmedlemmarna endast har minimal åtkomst till miljöer under kortast möjliga tid. Sätt principer på plats för att täcka administratörsåtkomsträttigheter på huvudenheter, DevOps-verktyg, versionspipelines, kodlagringsplatser, miljöer, hemliga arkiv och databaser. För DevOps-team är grundkravet en anslutning till organisationens identitetsarkiv. Använd identitetsfederation för att integrera med SaaS-miljöer för att undvika duplicering av identiteter på plattformar från tredje part och för att minska exponeringsrisken.
  • Använd inte personliga åtkomsttoken för källkodsåtkomst. Säkra metoder för DevOps-team omfattar åtkomst till SaaS-baserade DevOps-verktyg, kodlagringsplatser (via SSH, HTTPS eller personlig åtkomsttoken). För SaaS-baserad miljöåtkomst har du tydliga instruktioner för hur åtkomstprinciper avgör vem som kan ladda ned (klona) systemkodlagringsplatser och från vilka enheter (lokala enheter, moln och container). OneDrive kan till exempel blockera eller begränsa ohanterad enhetsåtkomst.
  • Standardisera och synkronisera GitHub Enterprise Managed User-användarkonton (EMU) med företagsidentiteter. Med Företagshanterade användare kan du styra användarkontona för dina företagsmedlemmar via din identitetsprovider (IdP). I organisationens identitetsarkiv definierar du uttryckligen GitHub-användarnamn, e-postmeddelanden och visningsnamn. Användarna kan sedan enkelt identifiera medarbetare även när de aldrig har träffats ansikte mot ansikte.
  • För de tre sätt som en utvecklare kan ansluta till en SaaS-miljö (HTTPS med en identitet, personlig åtkomsttoken, ansluta med SSH-nyckel) kan du upprätta anslutningar till organisationens identitetsarkiv. Med GitHub (förutom GitHub EMU-konton) är din identitet och kommer alltid att vara din offentliga identitet. Kontrollerad åtkomst via enkel inloggning kräver anslutning till organisationens identitetsarkiv.
  • Använd en SSH-certifikatutfärdare (CA) för att tillhandahålla signerade SSH-certifikat för medlemmar för säker åtkomst till resurser med Git. Ett SSH-certifikat är en mekanism för att en SSH-nyckel ska signera en annan SSH-nyckel. GitHub Enterprise Cloud stöder SSH-certifikat för att ge organisationer mer kontroll över hur medlemmar får åtkomst till lagringsplatser. Administratörer kan ladda upp sin offentliga SSH CA-nyckel och utfärda certifikat som medlemmar kan använda för Git-autentisering. Certifikat kan bara komma åt lagringsplatser som tillhör organisationen. Administratörer kan kräva att medlemmar använder certifikat vid åtkomst till sina lagringsplatser.
  • Använd en Git-autentiseringshanterare för att härda åtkomsten till din kod. Verktyg som Visual Studio (VS) har inbyggt identitetsstöd. VS Code skjuts upp till en Git-autentiseringshanterare.

Metodtips för grensäkerhet

När hackare får åtkomst till kodlagringsplatsen kan de studera systemsäkerhet och ändra kod utan att team märker det. För att förhindra obehörig åtkomst till kodlagringsplatsen implementerar du en förgreningsstrategi för att upprätta kontroll över kodändringar (se exemplet som illustreras i följande diagram).

Diagrammet visar ett exempel på en förgreningsstrategi som skyddar huvudlagringsplatsen.

Om du vill åtgärda potentiella åtkomstmöjligheter för lagringsplatser bör du överväga följande metodtips för grensäkerhet.

  • Skydda grenar med kodgranskningar för att ge DevOps-team kontroll över kodändringar och granskningsframsteg. Förgreningsstrategin i föregående diagram uttrycker ett kontrollerat flöde av ändringar som ger en tydlig kedja av kommandon och skisser för att hantera kodändringar. Av de olika metoderna för förgreningsstrategin är en gemensamhet att skyddade grenar fungerar som källa för nya versioner av produktion.
  • Låt administratörer för Git-lagringsplatser kontrollera godkännandeauktoriseringar. Kontrollmekanismen för förgreningsstrategier finns i arbetsflödet för godkännande. Skyddade grenar kräver valideringar, granskningar och godkännanden innan ändringar godkänns. Ett alternativ är att skapa en grenskyddsregel för att framtvinga arbetsflöden. Du kan till exempel kräva en godkännandegranskning eller statuskontroll för alla pull-begäranden som har sammanfogats med den skyddade grenen. Grenprinciper hjälper team att skydda viktiga utvecklingsgrenar. Principer tillämpar teamets standarder för kodkvalitet och ändringshantering.

Metodtips för att lita på verktyg, tillägg och integreringar

Utökningsbarhet i integrerade utvecklingsmiljöer (IDE) är så produktiv att det i huvudsak är en funktion som krävs. Du förlitar dig på möjligheten att tillämpa och kurera tillägg på marknadsplatsen för en specifik IDE för att utforma din optimala arbetsmiljö.

För att åtgärda säkra IDE:er bör du överväga följande metodtips för verktyg, tillägg och integrering.

  • Se till att du bara integrerar verktyg från både betrodda marknadsplatser och utgivare. Vs Code-marknadsplatsen har till exempel tusentals tillägg för att göra ditt liv enklare. Men när dina team använder nya verktyg eller tillägg kan den viktigaste aspekten vara att verifiera en utgivares tillförlitlighet.
  • Konfigurera säkra metoder för att styra tilläggsanvändningen för att begränsa attackytan i utvecklarmiljöer. De flesta IDE-tillägg kräver godkännande av vissa behörigheter för att fungera, ofta som en fil med läsbehörighet i systemet för att analysera kod. Tillägg kräver anslutningar till molnmiljöer för att fungera (vanliga i måttverktyg). Om du godkänner extra funktioner ovanpå IDE öppnas organisationer för fler hot.
  • På utvecklardatorer spårar du antalet och mognaden för använda tillägg för att förstå den potentiella attackytan. Införliva endast VS Code Marketplace-tillägg från verifierade utgivare. När du installerar programtillägg från tredje part med VS Code kontrollerar du regelbundet tillägg som du kör med kommandoraden, kod --list-extensions --show-versions. Ha en god förståelse för utökningsbara komponenter som du kör i utvecklarmiljön.

Nästa steg