Rekommendationer för att skydda en utvecklingslivscykel

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Security:

SE:02 Upprätthålla en säker utvecklingslivscykel med hjälp av en härdad, mestadels automatiserad och granskningsbar programvaruförsörjningskedja. Implementera en säker design genom att använda hotmodellering för att skydda mot implementeringar som motverkar säkerheten.

Relaterad guide: Hotanalys

Den här guiden beskriver rekommendationerna för att härda din kod, utvecklingsmiljö och programvaruförsörjningskedja genom att tillämpa rekommenderade säkerhetsmetoder under hela utvecklingscykeln. För att förstå den här vägledningen bör du ha kunskap om DevSecOps.

Ett diagram över säkerhetscykeln.

DevSecOps integrerar säkerhet i DevOps-processer genom att:

  • Automatisera säkerhetstestning och verifiering.

  • Implementera verktyg som säkerhetspipelines för att genomsöka kod och infrastruktur som kod (IaC) efter sårbarheter.

Kärnan i en arbetsbelastning är programkoden som implementerar affärslogik. Koden och processen för att utveckla kod måste vara fria från säkerhetsfel för att säkerställa konfidentialitet, integritet och tillgänglighet.

Det räcker inte att bara skydda infrastrukturplanet med hjälp av kontroller för identitet, nätverk och andra åtgärder. Förhindra felaktig implementering av kod eller ett komprometterat kodblock för att stärka din övergripande säkerhetsstatus. Användningsplanet, d.v.s. programkoden, måste också härdas. Processen för att integrera säkerhet i utvecklingslivscykeln är i grunden en härdningsprocess. Precis som resurshärdning är det också kontextagnostiskt att strama upp kodutvecklingen. Fokus ligger på att förbättra säkerheten och inte programmets funktionella krav. Information om härdning finns i Rekommendationer för härdning av resurser.

Definitioner

Period Definition
Security Development Lifecycle (SDL) En uppsättning metoder från Microsoft som stöder säkerhetskrav och efterlevnadskrav.
Livscykel för programvaruutveckling (SDLC) En multistage, systematisk process för utveckling av programvarusystem.

Viktiga designstrategier

Säkerhetsåtgärder bör integreras på flera punkter i din befintliga programvaruutvecklingslivscykel (SDLC) för att säkerställa:

  • Designval leder inte till säkerhetsluckor.

  • Programkod och konfiguration skapar inte sårbarheter på grund av exploaterbar implementering och felaktig kodning.

  • Programvara som förvärvas via leveranskedjan medför inte säkerhetshot.

  • Processer för programkod, kompilering och distribution har inte manipulerats.

  • Sårbarheter som avslöjas genom incidenter åtgärdas.

  • Oanvända tillgångar inaktiveras korrekt.

  • Efterlevnadskraven komprometteras inte eller minskas.

  • Granskningsloggning implementeras i utvecklarmiljöer.

Följande avsnitt innehåller säkerhetsstrategier för de vanliga faserna i SDLC.

Kravfas

Målet med kravfasen är att samla in och analysera funktionella och icke-funktionella krav för ett program eller en ny funktion i ett program. Den här fasen är viktig eftersom den underlättar skapandet av skyddsräcken som är skräddarsydda för programmets mål. Att skydda data och integritet för ditt program bör vara ett grundläggande krav under varje fas i utvecklingslivscykeln.

Tänk dig till exempel ett program som behöver stöd för kritiska användarflöden som gör det möjligt för användaren att ladda upp och manipulera data. Alternativen för säkerhetsdesign bör omfatta garantier för användarens interaktion med programmet, till exempel att autentisera och auktorisera användaridentiteten, endast tillåta tillåtna åtgärder på data och förhindra SQL-inmatning. På samma sätt kan du täcka icke-funktionella krav som tillgänglighet, skalbarhet och underhåll. Säkerhetsvalen bör omfatta segmenteringsgränser, brandväggens ingress och utgående trafik samt andra övergripande säkerhetsproblem.

Alla dessa beslut bör leda till en bra definition av programmets säkerhetsstatus. Dokumentera säkerhetskraven i en överenskommen specifikation och återspegla dem i kvarvarande uppgifter. Den bör uttryckligen ange de säkerhetsinvesteringar och kompromisser och risker som företaget är villigt att ta på sig om investeringarna inte godkänns av företagets intressenter. Du kan till exempel dokumentera behovet av att använda en brandvägg för webbaserade program (WAF) framför ditt program, till exempel Azure Front Door eller Azure Application Gateway. Om affärsintressenter inte är beredda att acceptera den extra kostnaden för att köra en WAF måste de acceptera risken att attacker på programnivå riktas mot programmet.

Insamling av säkerhetskrav är en viktig del av den här fasen. Utan den här ansträngningen baseras design- och implementeringsfaserna på ej underskattade val, vilket kan leda till säkerhetsluckor. Du kan behöva ändra implementeringen senare för att hantera säkerheten, vilket kan vara dyrt.

Designfas

Under den här fasen konverteras säkerhetskrav till tekniska krav. I din tekniska specifikation dokumenterar du alla designbeslut för att förhindra tvetydigheter under implementeringen. Här följer några vanliga uppgifter:

Definiera säkerhetsdimensionen för systemarkitekturen

Överlägg arkitekturen med säkerhetskontroller. Till exempel kontroller som är praktiska för isoleringsgränserna enligt segmenteringsstrategin, vilka typer av identiteter som krävs för programmets komponenter och vilken typ av krypteringsmetoder som ska användas. Några exempelarkitekturer finns i illustrationerna i avsnitten Exempel i artiklarna Identitets- och åtkomsthantering och Nätverk .

Utvärdera plattformar som tillhandahålls av affordances

Det är viktigt att förstå ansvarsfördelningen mellan dig och molnleverantören. Undvik till exempel överlappning med interna Azure-säkerhetskontroller. Du får bättre säkerhetstäckning och kan omallokera utvecklingsresurser till programmets behov.

Om din design till exempel anropar en brandvägg för webbaserade program vid ingress kan du avlasta ansvaret till en lastbalanserare som Application Gateway eller Azure Front Door. Undvik att replikera funktioner som anpassad kod i ditt program.

Välj endast betrodda ramverk, bibliotek och programvara för leveranskedjan. Din design bör också ange säker versionskontroll. Programberoenden ska hämtas från betrodda parter. Tredjepartsleverantörer bör kunna uppfylla dina säkerhetskrav och dela sin plan för ansvarigt avslöjande. Alla säkerhetsincidenter bör rapporteras omedelbart så att du kan vidta nödvändiga åtgärder. Vissa bibliotek kan också vara förbjudna för din organisation. Programvara kan till exempel vara säker från sårbarheter men ändå otillåten på grund av licensbegränsningar.

För att säkerställa att den här vägledningen följs av alla deltagare i programvaran ska du ha en lista över godkända och/eller icke godkända ramverk, bibliotek och leverantörer. När det är möjligt placerar du skyddsräcken i utvecklingspipelines för att stödja listan. Så mycket som möjligt kan du automatisera användningen av verktyg för att genomsöka beroenden efter sårbarheter.

Fastställ de säkerhetsdesignmönster som programkoden ska implementera.

Mönster kan stödja säkerhetsproblem som segmentering och isolering, stark auktorisering, enhetlig programsäkerhet och moderna protokoll. Vissa driftsmönster, till exempel karantänmönstret, kan hjälpa till att verifiera och blockera användningen av programvara som potentiellt kan medföra säkerhetsproblem.

Mer information finns i Designmönster för molnet som stöder säkerhet.

Lagra programhemligheter på ett säkert sätt

Implementera på ett säkert sätt användningen av programhemligheter och i förväg delade nycklar som programmet använder. Autentiseringsuppgifter och programhemligheter bör aldrig lagras i källkodsträdet. Använd externa resurser som Azure Key Vault för att säkerställa att ingen ytterligare åtkomst kan hämtas om källkoden blir tillgänglig för en potentiell angripare. I allmänhet kan du hitta sätt att undvika hemligheter. Att använda hanterade identiteter är när det är möjligt ett sätt att uppnå det målet. Mer information finns i Rekommendationer för att hantera programhemligheter.

Definiera testplaner

Definiera tydliga testfall för säkerhetskrav. Utvärdera om du kan automatisera dessa tester i dina pipelines. Om ditt team har processer för manuell testning ska du inkludera säkerhetskrav för dessa tester.

Anteckning

Utför hotmodellering under den här fasen. Hotmodellering kan bekräfta att designvalen är anpassade till säkerhetskrav och exponerar luckor som du bör minska. Om din arbetsbelastning hanterar mycket känsliga data investerar du i säkerhetsexperter som kan hjälpa dig att utföra hotmodellering.

Den inledande hotmodelleringsövningen bör ske under designfasen när programvarans arkitektur och design på hög nivå definieras. När du gör det under den fasen kan du identifiera potentiella säkerhetsproblem innan de införlivas i systemets struktur. Den här övningen är dock inte en engångsaktivitet. Det är en kontinuerlig process som bör fortsätta under hela programvarans utveckling.

Mer information finns i Rekommendationer för hotanalys.

Utvecklings- och testfas

Under den här fasen är målet att förhindra säkerhetsfel och manipulering av kod-, bygg- och distributionspipelines.

Vara välutbildad i säkra kodmetoder

Utvecklingsteamet bör ha formell och specialiserad utbildning i säker kodning. Webb- och API-utvecklare kan till exempel behöva specifik utbildning för att skydda sig mot skriptattacker över flera platser, och backend-utvecklare kan dra nytta av djupgående träning för att undvika attacker på databasnivå som SQL-inmatningsattacker.

Utvecklare bör vara skyldiga att slutföra den här utbildningen innan de kan få åtkomst till produktionskällans källkod.

Du bör också utföra interna peer-kodgranskningar för att främja kontinuerlig inlärning.

Använda säkerhetstestverktyg

Utför hotmodellering för att utvärdera säkerheten i programmets arkitektur.

Använd säkerhetstestning för statiska program (SAST) för att analysera kod för säkerhetsrisker. Integrera den här metoden i utvecklarmiljön för att identifiera sårbarheter i realtid.

Använd DAST (Dynamic Application Security Testing) under körning. Den här verktygskedjan kan söka efter fel i säkerhetsdomäner och simulera en uppsättning attacker för att testa programmets säkerhetsresiliens. När det är möjligt integrerar du det här verktyget i dina byggpipelines.

Följ branschstandarder för säkra kodningsmetoder. Mer information finns i avsnittet Community-resurser i den här artikeln.

Använd linters och kodanalysverktyg för att förhindra att autentiseringsuppgifter skickas till källkodslagringsplatsen. Till exempel inspekterar .NET Compiler Platform (Roslyn) Analysverktyg programkoden.

Under byggprocessen använder du pipelinetillägg för att fånga autentiseringsuppgifterna i källkoden. Genomsök alla beroenden, till exempel bibliotek från tredje part och ramverkskomponenter, som en del av processen för kontinuerlig integrering. Undersök sårbara komponenter som flaggas av verktyget. Kombinera den här uppgiften med andra kodgenomsökningsuppgifter som inspekterar kodomsättning, testresultat och täckning.

Använd en kombination av tester. Information om säkerhetstestning i allmänhet finns i Rekommendationer för säkerhetstestning.

Skriv precis tillräckligt med kod

När du minskar din kodfotavtryck minskar du också risken för säkerhetsfel. Återanvänd kod och bibliotek som redan används och som har gått igenom säkerhetsvalidering i stället för att duplicera kod.

Att dra nytta av Azure-funktioner är ett annat sätt att förhindra onödig kod. Ett sätt är att använda hanterade tjänster. Mer information finns i Använda PaaS-alternativ (Plattform som en tjänst).

Skriv kod med en neka-alla-metod som standard. Skapa endast tillåtna listor för entiteter som behöver åtkomst. Om du till exempel har kod som måste avgöra om en privilegierad åtgärd ska tillåtas, bör du skriva den så att neka-resultatet är standardfallet och att det tillåtna resultatet endast inträffar när det är specifikt tillåtet med kod.

Skydda utvecklarmiljöer

Utvecklararbetsstationer måste skyddas med starka nätverks- och identitetskontroller för att förhindra exponering. Kontrollera att säkerhetsuppdateringar tillämpas noggrant.

Byggagenter är mycket privilegierade och har åtkomst till byggservern och koden. De måste skyddas med samma stränghet som dina arbetsbelastningskomponenter. Det innebär att åtkomst till byggagenter måste autentiseras och auktoriseras, att de ska vara nätverkssegmenterade med brandväggskontroller, att de ska genomgå sårbarhetsgenomsökning och så vidare. Microsoft-värdbaserade byggagenter bör föredras framför lokalt installerade byggagenter. Microsoft-värdbaserade agenter ger fördelar som rena virtuella datorer för varje körning av en pipeline.

Anpassade byggagenter lägger till hanteringskomplexitet och kan bli en attackvektor. Autentiseringsuppgifterna för att skapa datorer måste lagras på ett säkert sätt och du måste regelbundet ta bort eventuella tillfälliga byggartefakter från filsystemet. Du kan uppnå nätverksisolering genom att endast tillåta utgående trafik från byggagenten, eftersom den använder pull-modellen för kommunikation med Azure DevOps.

Källkodslagringsplatsen måste också skyddas . Bevilja åtkomst till kodlagringsplatser på behovsbasis och minska exponeringen av säkerhetsrisker så mycket som möjligt för att undvika attacker. Ha en grundlig process för att granska kod för säkerhetsrisker. Använd säkerhetsgrupper för det ändamålet och implementera en godkännandeprocess som baseras på affärsmotiveringar.

Säkra koddistributioner

Det räcker inte att bara skydda kod. Om den körs i exploaterbara pipelines är alla säkerhetsinsatser meningslösa och ofullständiga. Bygg- och versionsmiljöer måste också skyddas eftersom du vill förhindra att dåliga aktörer kör skadlig kod i pipelinen.

Upprätthålla en uppdaterad inventering av varje komponent som är integrerad i ditt program

Varje ny komponent som är integrerad i ett program ökar attackytan. För att säkerställa korrekt ansvar och aviseringar när nya komponenter läggs till eller uppdateras bör du ha en inventering av dessa komponenter. Lagra den utanför byggmiljön. Kontrollera regelbundet att manifestet matchar vad som finns i byggprocessen. På så sätt ser du till att inga nya komponenter som innehåller bakdörrar eller annan skadlig kod läggs till oväntat.

Pipelineaktiviteter

  • Hämta uppgifter i pipelinen från betrodda källor, till exempel Azure Marketplace. Kör uppgifter som skrivs av pipelineleverantören. Vi rekommenderar GitHub-uppgifter eller GitHub Actions. Om du använder GitHub-arbetsflöden föredrar du Microsoft-redigerade uppgifter. Verifiera även uppgifter eftersom de körs i säkerhetskontexten för din pipeline.

  • Pipelinehemligheter. Distributionstillgångar som körs i en pipeline har åtkomst till alla hemligheter i pipelinen. Ha rätt segmentering på plats för olika faser av pipelinen för att undvika onödig exponering. Använd hemliga butiker som är inbyggda i pipelinen. Kom ihåg att du kan undvika att använda hemligheter i vissa situationer. Utforska användningen av arbetsbelastningsidentiteter (för pipelineautentisering) och hanterade identiteter (för tjänst-till-tjänst-autentisering).

Hålla olika miljöer åtskilda

Data som används i olika miljöer måste hållas åtskilda. Produktionsdata bör inte användas i lägre miljöer eftersom dessa miljöer kanske inte har de strikta säkerhetskontroller som produktionen har. Undvik att ansluta från ett icke-produktionsprogram till en produktionsdatabas och undvik att ansluta icke-produktionskomponenter till produktionsnätverk.

Progressiv exponering

Använd progressiv exponering för att släppa funktioner för en delmängd användare baserat på valda kriterier. Om det uppstår problem minimeras effekten för dessa användare. Den här metoden är en vanlig strategi för riskreducering eftersom den minskar ytan. När funktionen mognar och du har större förtroende för säkerhetsgarantier kan du gradvis släppa den till en bredare uppsättning användare.

Produktionsfas

Produktionsfasen utgör den sista ansvarsfulla möjligheten att åtgärda säkerhetsluckor. Behåll en post med den gyllene avbildningen som släpps i produktion.

Behåll versionsartefakter

Behåll en katalog över alla distribuerade tillgångar och deras versioner. Den här informationen är användbar under incidenttriage, när du åtgärdar problem och när du får systemet tillbaka till fungerande tillstånd. Versionstillgångar kan också jämföras med publicerade CVE-meddelanden (Common Vulnerabilities and Exposures). Du bör använda automatisering för att utföra dessa jämförelser.

Nödkorrigeringar

Din automatiserade pipelinedesign bör ha flexibiliteten att stödja både regelbundna distributioner och nöddistributioner. Den här flexibiliteten är viktig för att stödja snabba och ansvarsfulla säkerhetskorrigeringar.

En version är vanligtvis associerad med flera godkännandegrindar. Överväg att skapa en nödsituationsprocess för att påskynda säkerhetskorrigeringar. Processen kan omfatta kommunikation mellan team. Pipelinen bör möjliggöra snabba distributioner för vidare- och återställning som hanterar säkerhetskorrigeringar, kritiska buggar och koduppdateringar som inträffar utanför den vanliga distributionslivscykeln.

Anteckning

Prioritera alltid säkerhetskorrigeringar framför bekvämlighet. En säkerhetskorrigering bör inte medföra en regression eller bugg. Om du vill påskynda korrigeringen via en nödpipeline bör du noga överväga vilka automatiserade tester som kan kringgås. Utvärdera värdet för varje test mot körningstiden. Enhetstester slutförs till exempel vanligtvis snabbt. Integrerings- eller slutpunkt-till-slutpunkt-tester kan köras under lång tid.

Underhållsfas

Målet med den här fasen är att se till att säkerhetsstatusen inte förfaller med tiden. SDLC är en pågående agil process. Begrepp som beskrivs i föregående faser gäller för den här fasen eftersom kraven ändras över tid.

Korrigeringshantering. Håll program, bibliotek och infrastrukturkomponenter uppdaterade med säkerhetskorrigeringar och uppdateringar.

Kontinuerlig förbättring. Kontinuerligt utvärdera och förbättra säkerheten i programutvecklingsprocessen genom att ta hänsyn till kodgranskningar, feedback, lärdomar och växande hot.

Inaktivera äldre tillgångar som är inaktuella eller inte längre används. Detta minskar programmets yta.

Underhållet omfattar även incidentkorrigeringar. Om problem hittas i produktion måste de omedelbart integreras tillbaka i processen så att de inte återkommer.

Förbättra kontinuerligt dina säkra kodningsmetoder för att hålla jämna steg med hotlandskapet.

Azure-underlättande

Microsoft Security Development Lifecycle (SDL) rekommenderar säkra metoder som du kan tillämpa på din utvecklingslivscykel. Mer information finns i Microsofts livscykel för säkerhetsutveckling.

Defender för DevOps och SAST-verktygen ingår som en del av GitHub Advanced Security eller Azure DevOps. De här verktygen kan hjälpa dig att spåra en säkerhetspoäng för din organisation.

Följ de Azure-säkerhetsrekommendationer som beskrivs i dessa resurser:

Om du vill hitta autentiseringsuppgifter i källkoden bör du överväga att använda verktyg som GitHub Advanced Security och OWASP-källkodsanalysverktyg.

Verifiera säkerheten för all öppen källkod i ditt program. Dessa kostnadsfria verktyg och resurser kan hjälpa dig med din utvärdering:

Säkerhetskontrollista

Se den fullständiga uppsättningen rekommendationer.

Säkerhetskontrollista