Dela via

Rekommendationer för att säkerställa livscykeln för utveckling

  • Artikel

Gäller för den här Power Platform rekommendationen för checklista för Well-Architected Security:

SE:02 Upprätthålla en säker livscykel för utveckling genom att använda en härdad, främst automatiserad och granskningsbar leveranskedja för programvara. Införliva en säker design genom att använda hotmodeller och skydda mot implementeringar som gäller överlistar säkerheten.

Den här guiden beskriver rekommendationer för att säkra din kod och utvecklingsmiljö genom att tillämpa bästa säkerhetspraxis under hela utvecklingscykeln.

Kärnan i en arbetsbelastning är komponenterna som implementerar affärslogiken. Komponenterna kan vara en blandning av lågkodselement som appar och flöden och kod för första element som plugin-program. Alla komponenter som utgör arbetsbelastningen måste vara fria från säkerhet för att säkerställa sekretess, integritet och tillgänglighet.

Att skydda infrastrukturen med identitets- och nätverkskontroller är viktigt, men det räcker inte. Förhindra dålig implementering av Power Platform arbetsbelastningar och äventyrade aktiviteter i dessa arbetsbelastningar för att stärka din övergripande säkerhetsställning. Processen att föra in säkerhet i utvecklingsprocessens livscykel beror på en härdningsprocess. Precis som resurshärdning är en skärpning av kodutveckling också kontextagnostisk. Fokus ligger på att öka säkerheten, inte på programmets funktionskrav.

Definitioner

Begrepp Definition
Security Development Lifecycle (SDL) En uppsättning praxis tillhandahållen av Microsoft som stöder säkerhetsförsäkring och efterlevnadskrav.
Software development lifecycle (SDLC) En systematisk process för utveckling av programvarusystem i flera steg.

Viktiga designstrategier

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

  • Designval leder inte till säkerhetsluckor.
  • Lågkod och kodfokuserade komponenter samt konfiguration skapar inte sårbarheter på grund av exploateringsbar implementering och felaktig kodning.
  • Lågkod och kodfokuserade komponenter och distributionsprocesser fungerar inte som de ska.
  • Säkerhetsrisker som avslöjas genom incidenter åtgärdas.
  • Regelefterlevnadskraven varken påverkas eller minskas.
  • Granskningsloggning implementeras i alla miljöer.

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

Kravfas

Målet med kravfasen är att samla in och analysera de funktionskrav som ställs på en arbetsbelastning eller en ny funktion i en arbetsbelastning. Den här fasen är viktig eftersom den underlättar skapandet av skräddarsydda lösningar för arbetsbelastningens mål. Att skydda data och integriteten för arbetsbelastningen bör vara ett grundläggande krav under alla faser av utvecklingens livscykel.

Tänk till exempel på en arbetsbelastning där användare anger och ändrar data i ett program. Alternativen för säkerhetsdesign bör omfatta garantier för användarens interaktion med dessa data, t.ex. att autentisera och auktorisera användaridentiteten, och endast tillåta tillåtna åtgärder i dessa data. Icke-funktionella krav omfattar tillgänglighet, användbarhet och underhållsbarhet. Säkerhetsval bör inkludera segmenteringsgränser, brandväggsingång och -utgång samt andra tvärgående säkerhetsfrågor.

Alla dessa beslut bör leda till en bra definition av säkerheten för arbetsbelastningen. Dokumentera säkerhetskraven i en avtalad specifikation och återspegla dem i eftersläpande data. Dokumentet bör uttryckligen ange säkerhetsinvesteringarna och de avvägningar och risker som företaget ä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 IP-brandvägg i Power Platform-miljöer för att skydda organisationsdata genom att förhindra åtkomst till Dataverse till endast tillåtna IP-platser. Om affärsintressenter inte är villiga att bära den extra kostnaden för att använda en lösning som hanterade miljöer, måste de vara beredda att acceptera risken att organisationsresurserna nås från offentliga platser, t.ex. ett kafé. Anta som ett annat exempel att programmet måste ansluta till en tredjeparts datakälla. Power Platform kan ha ett färdigt anslutningsprogram för detta, men kanske inte stöder autentiseringskraven som har godkänts av dina säkerhetsteam. I så fall kanske dina säkerhetsintressenter accepterar risken att använda en autentiseringsmetod som inte har godkänts. Du kan också utforska hur du använder ett anpassat anslutningsprogram, samtidigt som du får se fördelarna med ökad utvecklingstid och potentiell projektfördröjning.

Insamling av säkerhetskrav är en kritisk del av denna fas. Utan denna insats kommer design- och implementeringsfaserna att baseras på outtalade val, vilket kan leda till säkerhetsluckor eller förändrade krav som ökar utvecklingstiden. Du kan behöva ändra implementeringen senare så att den innehåller säkerhetsroller, vilket kan vara dyrt.

Designfas

Under den här fasen konverteras säkerhetskraven till tekniska krav. Dokumentera alla designbeslut i din tekniska specifikation för att förhindra oklarheter under implementeringen. Här följer några vanliga uppgifter:

  • Definiera arkitekturens säkerhetsstruktur. Arkitekturen med säkerhetskontroller. Kontroller som till exempel är praktiska för avgränsningsgränserna för nätverket, de typer av identiteter och autentiseringsmetoder som behövs för komponenterna i arbetsbelastningen och vilken typ av krypteringsmetoder som ska användas.

  • Utvärdera plattformsförsedda förmåner. Det är viktigt att du förstår ansvarsfördelning mellan dig och Power Platform. Undvik överlappning eller dupliceras med Power Platform inbyggda säkerhetskontroller. Du får bättre säkerhetsskydd och kan omfördela utvecklingsresurser efter programmets behov.

    Till exempel, istället för att skapa anpassad logik som reaktivt identifierar och varnar för oauktoriserade användningsmönster i appar och flöden, använd policyer för förebyggande av dataförlust för att kategorisera hur anslutningsprogram kan användas.

    Välj endast betrodda referensimplementeringar, mallar, kodkomponenter, skript och bibliotek. Vid utformningen bör du även ange säker versionskontroll. Programberoenden ska komma från betrodda parter. Tredjepartsleverantörer bör kunna uppfylla dina säkerhetskrav och dela med sig av sin ansvarsfulla plan för avslöjande. Alla säkerhetsincidenter ska rapporteras omgående så att du kan utföra nödvändiga åtgärder. Vissa bibliotek eller referensimplementeringar kan också vara förbjudna av organisationen. Även om det till exempel är säkert och fritt från säkerhetsproblem kan det ändå inte godkännas eftersom funktioner som ännu inte har godkänts av organisationen används, licensbegränsningar eller supportmodellen för referensimplementering.

    Se till att vägledningen följs genom att underhålla en lista med godkända och/eller för godkännande ramverk, bibliotek och leverantörer och se till att beslutsfattare känner till listan. Om det är möjligt placerar du skyddsmekanismer i utvecklingspipelines som stöd för listan. I så hög grad som möjligt kan du automatisera användningen av verktyg för att söka efter säkerhetsproblem.

  • Lagra programhemligheter på ett säkert sätt. Implementera användningen av programhemligheter och fördelade nycklar som programmet använder. Autentiseringsuppgifter och programhemlighet bör aldrig lagras i källkoden för arbetsbelastningen (app eller flöde). Använd externa resurser som Azure Key Vault för att säkerställa att om din källkod blir tillgänglig för en potentiell angripare så får du ingen ytterligare åtkomst.

  • Anslut till din data säkert. Använd de kraftfulla säkerhetsfunktionerna som Microsoft Dataverse erbjuder för att skydda dina data, t.ex. rollbaserade säkerhetsfunktioner och kolumnsäkerhet. För andra datakällor bör du använda anslutningar med säkra autentiseringsmetoder. Undvik frågor där användarnamn och lösenord lagras i oformaterad text. Undvik HTTP för att skapa anpassade anslutningsprogram.

  • Definiera hur slutanvändare ska interagera med arbetsbelastningen och data. Fundera på om användarna kommer att ha direkt åtkomst till data, vilken åtkomstnivå de behöver och varifrån de ska komma åt informationen. Fundera på hur programmen ska delas med slutanvändarna. Se till att endast de som behöver åtkomst till appen och data har åtkomst. Undvik komplexa säkerhetsmodeller som uppmuntrar till lösningar för att undvika säkerhetsblockering.

  • Undvik hårdkodning. Undvik hårdkodning av URL:er och nycklar. Undvik till exempel att hårdkoda i en Power Automate HTTP-åtgärd den URL eller nyckeln till serverdelstjänsten. Använd i stället en anpassad anslutningsprogram eller använd en miljövariabel för URL:en och Azure Key Vault för API-nyckeln.

  • Definiera testplaner. Definiera klara 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 inkluderar du säkerhetskraven för dessa tester.

Kommentar

Utför hotmodellering under den här fasen. Hotmodellering kan bekräfta att designval är anpassade efter säkerhetskraven och visar risker som du bör undvika. Om arbetsbelastningen hanterar mycket känsliga data är det en säkerhetsexpert som kan hjälpa dig att utföra hotmodellering.

Den första hotmodelleringsövningen ska ske under designfasen när programvarans arkitektur och utformning på hög nivå definieras. Om du gör det under den fasen kan du identifiera potentiella säkerhetsproblem innan de ingår i systemets struktur. Den här övningen är emellertid inte en engångsaktivitet. Det är en kontinuerlig process som ska fortsätta genom hela programvaran.

Mer information finns i Rekommendationer om hotanalys.

Utvecklings- och testfas

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

Vara välutbildad i säker kodpraxis

Utvecklingsteamet bör ha utbildning i säkra kodmetoder. Till exempel bör utvecklare vara bekanta med säkerhetskoncept i Microsoft Dataverse för att implementera en säkerhetsmodell med minst privilegier, innehållssäkerhetspolicyer för modellbaserade appar för att begränsa inbäddning till betrodda domäner och autentiseringsmetoder för anslutningsprogram/lokal gateway.

Utvecklare bör vara obligatoriska för att slutföra utbildningen innan de börjar arbeta med Power Platform arbetsbelastningen.

Utför interna referensgranskningar för att främja kontinuerligt lärande.

Använda kodanalysverktyg

Lösningskontrollen bör användas för Power Platform-resurser och källkoden för en vanlig kod kan kontrolleras med säkerhet, till exempel med autentiseringsuppgifter i kod. Identifiera möjliga förekomster av autentiseringsuppgifter och identifiering i källkods- och konfigurationsfiler. Det här är en bra tid att granska hur anslutningsautentisering ska hanteras i produktion.

Utföra fuzztestning

Använd felaktiga och oväntade data för att kontrollera säkerhetsproblem och verifiera felhantering, särskilt viktiga för lösningar som innehåller Power Pages.

Skriv bara tillräckligt med kod

När du minskar ditt kodavtryck minskar du också risken för säkerhetsfel. Återanvänd kod och bibliotek som redan används och som har genomgått säkerhetsvalideringar i stället för att duplicera kod. Identifiering av programvara med öppen källkod och kontroll av version, ansvar och rättsliga skyldigheter. Det finns en ökad mängd Power Platform-resurser med öppen källkod så detta bör inte förbises. När det är möjligt bör detta diskuteras under designfasen för att undvika sista-minuten-problem.

Skydda utvecklarmiljöer

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

Källkodsförrådet måste också skyddas . Ge tillgång till koddatabaser för att få nödvändig information och minska exponeringen för sårbarheter så mycket som möjligt för att undvika angrepp. Ha en grundlig process för att granska kod för säkerhetsrisker. Använd säkerhetsgrupper för det syftet och implementera en godkännandeprocess som bygger på företagets funktion.

Säker koddistribution

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 lanseringsmiljöer måste också skyddas eftersom du vill förhindra att dåliga aktörer kör skadlig kod i din pipeline.

Upprätthålla ett uppdaterat lager av alla komponenter som är integrerade i programmet

Varje ny komponent som är integrerad i en applikation ökar angreppsytan. För att säkerställa korrekt ansvarighet och avisering när nya komponenter läggs till eller uppdateras bör du ha en inventering av dessa komponenter. Kontrollera regelbundet att ditt manifest matchar det som finns i din skapandeprocess. Att göra det hjälper till att säkerställa att inga nya komponenter som innehåller bakdörrar eller annan skadlig programvara läggs till oväntat.

Vi rekommenderar att du använder pipelines för Power Platform för dina distributioner. Utöka pipelines med GitHub Actions. Om du använder GitHub-arbetsflöden föredrar du Microsoft-författade uppgifter. Verifiera även uppgifter eftersom de körs i säkerhetskontexten för din pipeline.

Utforska användningen av tjänsthuvuden för distribution.

Produktionsfas

Produktionsfasen utgör den sista ansvariga affärsmöjligheten för att korrigera säkerhetsluckor. Spara en post över den bild som har släppts i produktion.

Behåll versionshanterade artefakter

Spara en katalog över alla distribuerade tillgångar och deras versioner. Den här informationen är användbar under sortering av incidenter, när du mildrar problem och när du återställer systemet till att fungera. 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 göra dessa jämförelser.

Nödkorrigeringar

Din automatiserade pipelinedesign bör ha flexibiliteten att stödja både regelbundna och nödsituationer. Den här flexibiliteten är viktig för att kunna åtgärda snabba och ansvariga säkerhetskorrigeringar.

En utgåva är vanligtvis associerad med flera godkännandegrindar. Överväg att skapa en process som kan öka hastigheten på säkerhetskorrigeringarna. Processen kan innefatta kommunikation mellan team. Pipeline bör tillåta snabba framåt- och tillbakarullningsdistributioner som hanterar säkerhetskorrigeringar, kritiska problem och koduppdateringar som inträffar utanför den vanliga distributionscykeln.

Kommentar

Prioritera alltid säkerhetskorrigeringar framför bekvämlighet. En säkerhetskorrigering bör inte introducera ett fel eller ett fel. Om du vill öka hastigheten på korrigeringen med hjälp av en pipeline bör du tänka på vilka automatiserade tester som kan kringgås. Utvärdera värdet för varje test mot körningstiden. Enhetstester slutförs till exempel oftast snabbt. Integrerings- eller heltäckande tester kan köras under en längre tid.

Se till att olika miljöer är separata

Produktionsdata bör inte användas i lägre miljöer** eftersom dessa miljöerna kanske inte har de säkerhetskontroller som produktionsmiljön har. Undvik att ansluta från en icke-produktionsapp till en produktionsdatabas och undvik att ansluta icke-produktionskomponenter till produktionsnätverk.

Använd progressiv exponering

Använd progressiv exponering för att släppa funktioner till en undergrupp av användare baserat på valda kriterier. Om det finns problem minimeras påverkan för användarna. Detta tillvägagångssätt är en vanlig riskreducerande strategi eftersom den minskar ytan. När funktionen mognar och du har mer förtroende för säkerhetsgarantier, kan du gradvis släppa den till en bredare uppsättning användare.

Underhållsfas

Målet med den här fasen är att säkerställa att säkerheten inte fungerar över tid. SDLC är en pågående smidig process. Begrepp som behandlas i de föregående faserna gäller för den här fasen eftersom kraven ändras med tiden.

Kontinuerlig förbättring. Kontinuerligt utvärdera och förbättra säkerheten för programvaruutvecklingsprocessen genom att ta hänsyn till kodgranskning, feedback, lärdomar och föränderliga hot och även nya funktioner som görs tillgängliga av Power Platform.

Inaktivera äldre tillgångar som är inaktuella eller inte längre används. Om du gör det minskas programmets yta.

Underhåll innehåller även incidentkorrigeringar. Om problem påträffas i produktionen måste de snabbt integreras tillbaka i processen så att de inte uppstår igen.

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

SDL i Microsoft Power Platform

Power Platform bygger på en metodologi och en metod för säker design. Både kultur och metodologi stärks konstant genom Microsofts branschledande metoder för Security Development Lifecycle (SDL) och hotmodellering.

Den robusta granskningsprocessen av hotmodeller säkerställer att hot identifieras under designfasen, mildras och valideras för att säkerställa att de har mildrats.

Hotmodellering står också för alla ändringar av tjänster som redan sker kontinuerligt genom regelbundna granskningar. Om du använder STRIDE-modellen kan du lösa de vanligaste problemen med en osäker design.

Microsoft SDL är en motsvarighet till OWASP försäkringsmognadsmodell för programvara (SAMM). Båda bygger på att säker design ingår i webbprogrammets säkerhet. Mer information finns i OWASP topp 10 risker: riskreduceringar i Power Platform.

Underlätta Power Platform

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

Defender för DevOps och SAST-verktygen (Static Application Security Testing) ingår som en del av GitHub Advanced Security och Azure DevOps. Med de här verktygen kan du spåra en säkerhetspoäng för organisationen.

Med funktionen för lösningskontroll kan du utforma en omfattande statisk analyskontroll på dina lösningar mot en uppsättning regler och snabbt identifiera dessa problemmönster. Se Använda lösningskontroll för att verifiera lösningar.

Checklista för säkerhet

Se den fullständiga uppsättningen med rekommendationer.

Checklista för säkerhet