Dela via

Rekommendationer för att skydda en utvecklingslivscykel

  • Artikel

Gäller för den här checklistan 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. Införliva en säker design med hjälp av hotmodellering för att skydda mot säkerhetsnedsättande implementeringar.

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 och nätverk och andra mått. 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å sammanhangsberoende 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 systematisk process för utveckling av programvarusystem.

Viktiga designstrategier

Säkerhetsåtgärder bör integreras på flera punkter i din befintliga SDLC (Software Development Lifecycle) 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 felaktiga kodningsmetoder.

  • Programvara som hämtas via leveranskedjan medför inte säkerhetshot.

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

  • Sårbarheter som avslöjas via incidenter minimeras.

  • Oanvända tillgångar inaktiveras korrekt.

  • Efterlevnadskraven är inte komprometterade eller minskade.

  • Granskningsloggning implementeras i utvecklarmiljöer.

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

Samla in och dokumentera säkerhetskrav

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, som att autentisera och auktorisera användaridentiteten, endast tillåta tillåtna åtgärder på data och förhindra SQL-inmatning. På samma sätt täcker du icke-funktionella krav som tillgänglighet, skalbarhet och underhåll. Säkerhetsval bör omfatta segmenteringsgränser, brandväggs-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. Det bör uttryckligen ange de säkerhetsinvesteringar och kompromisser och risker som verksamheten är villig att ta på sig om investeringarna inte godkänns av affärsintressenter. Du kan till exempel dokumentera behovet av att använda en brandvägg för webbprogram (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 för att programnivåattacker 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å diskreta val, vilket kan leda till säkerhetsluckor. Du kan behöva ändra implementeringen senare för att hantera säkerheten, vilket kan vara dyrt.

Översätta säkerhetskrav till tekniska krav

Under designfasen konverteras säkerhetskrav till tekniska krav. I din tekniska specifikation dokumenterar du alla designbeslut för att förhindra tvetydighet 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 plattformsspecifika priser

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

Om din design till exempel kräver en brandvägg för webbprogram vid ingress kan du avlasta det 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 ansvarsfulla informationsplan. 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 mot 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 automatiserar du 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 driftmönster, till exempel karantänmönstret, kan hjälpa till att verifiera och blockera användningen av programvara som potentiellt kan medföra säkerhetsrisker.

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 ditt program använder. Autentiseringsuppgifter och programhemligheter bör aldrig lagras i källkodsträdet. Använd externa resurser som Azure Key Vault för att se till 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.

Kommentar

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 minimera. 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.

Säkra metoder för utveckling och testning

Under utvecklings- och testfasen ä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äkra kodningsmetoder. Webb- och API-utvecklare kan till exempel behöva specifik utbildning för att skydda mot skriptattacker mellan webbplatser, och backend-utvecklare kan dra nytta av djupgående utbildning 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 verktyg för säkerhetstest

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

Använd säkerhetstestning för statiska program (SAST) för att analysera kod för sårbarheter. 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 din programkod.

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 tillräckligt med kod

När du minskar ditt kodfotavtryck minskar du också risken för säkerhetsfel. Återanvänd kod och bibliotek som redan används och 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 behöver 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 åtkomsten 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. Autentiseringsuppgifter 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årbarheter 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.

Skydda kod i distributionspipelines

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.

Underhå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 ansvarsskyldighet 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 din byggprocess. 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.

Pipelineuppgifter

  • Hämta uppgifter i pipelinen från betrodda källor, till exempel Azure Marketplace. Kör uppgifter som är skrivna 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 steg i 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åll 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 lanseringsfunktioner för en delmängd användare baserat på valda kriterier. Om det finns 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.

Skydda kod i produktion

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

Behåll versionshanterade artefakter

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. Versionshanterade tillgå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 snabb distribution av återställning och återställning som hanterar säkerhetskorrigeringar, kritiska buggar och koduppdateringar som inträffar utanför den vanliga distributionslivscykeln.

Kommentar

Prioritera alltid säkerhetskorrigeringar framför bekvämlighet. En säkerhetskorrigering bör inte introducera 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.

Upprätthålla kodsäkerhet under hela livscykeln

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

Uppdateringshantering. Håll programvaru-, biblioteks- och infrastrukturkomponenter uppdaterade med säkerhetskorrigeringar och uppdateringar.

Kontinuerlig förbättring. Utvärdera och förbättra säkerheten i programutvecklingsprocessen kontinuerligt 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 det finns problem i produktionen måste de omedelbart integreras i processen igen 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 Microsoft Security Development Lifecycle.

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 analysverktyg för OWASP-källkod.

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