Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för den här säkerhetschecklistrekommendationen i Power Platform Well-Architected:
| 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. Anamma säker design genom att använda hotmodellering för att skydda mot implementeringar som undergräver 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. Dessa komponenter kan vara en blandning av lågkodselement som canvasappar och flöden, och kodbaserade element som pluginer. 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 bristfällig implementering av Power Platforms arbetsbelastningar och komprometterade aktiviteter i dessa arbetsbelastningar för att stärka din övergripande säkerhetsstatus. Processen att integrera säkerhet i din utvecklingslivscykel är i grunden en process för att härda systemet. 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 |
|---|---|
| SDL (Security Development Lifecycle) | En uppsättning praxis tillhandahållen av Microsoft som stöder säkerhetsförsäkring och efterlevnadskrav. |
| Livscykel för programvaruutveckling (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 funktionella och icke-funktionella kraven för en arbetsbelastning eller en ny funktion i en arbetsbelastning. Den här fasen är viktig eftersom den underlättar att skapa skyddsmekanismer som är anpassade efter arbetsbelastningens mål. Att skydda data och integritet i din arbetsbelastning bör utgöra ett grundläggande krav genom alla faser i utvecklingslivscykeln.
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 väl definierad säkerhetsstatus för arbetsbelastningen. Dokumentera säkerhetskraven i en överenskommen specifikation och avspegla dem i backloggen. 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 redo att acceptera risken för att organisationsresurser nås från offentliga platser, till exempel 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. Alternativt kan du överväga att använda en anpassad anslutning, samtidigt som du väger fördelarna mot den ökade utvecklingstiden och den potentiella projektförseningen.
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 för att uppfylla säkerhetskrav, vilket kan vara kostsamt.
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. Komplettera 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 plattformens funktioner. Det är viktigt att du förstår ansvarsfördelning mellan dig och Power Platform. Undvik överlappning eller duplicering av Power Platforms inbyggda säkerhetskontroller. Du får bättre säkerhetsskydd och kan omfördela utvecklingsresurser efter programmets behov.
I stället för att till exempel skapa anpassad logik som reaktivt identifierar och aviseringar om icke godkända användningsmönster i appar och flöden använder du dataprinciper för att kategorisera hur anslutningsappar 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.
För att säkerställa att dessa riktlinjer följs bör ni upprätthålla en lista över godkända och/eller icke godkända ramverk, bibliotek och leverantörer samt säkerställa att era utvecklare känner till denna lista. 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 i förväg delade nycklar som din applikation använder på ett säkert sätt. 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 när du skapar anpassade anslutningsappar.
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 i en HTTP-åtgärd i Power Automate hårdkoda URL:en eller nyckeln till backend-tjänsten. Använd i stället en anpassad anslutningsapp eller en miljövariabel för URL-adressen 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 din arbetsbelastning hanterar mycket känsliga data bör du investera i säkerhetsexperter som kan hjälpa dig att genomfö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 bör fortgå under hela programvarans utveckling.
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 behöva genomföra den här utbildningen innan de börjar arbeta med Power Platform-arbetsbelastningar.
Utför interna referensgranskningar för att främja kontinuerligt lärande.
Använda kodanalysverktyg
Solution Checker bör användas för Power Platform-resurser, och källkod i traditionella program kan kontrolleras för potentiella säkerhetsbrister, inklusive förekomst av autentiseringsuppgifter i koden. Identifiera möjliga exponeringar av autentiseringsuppgifter och hemligheter i källkod och konfigurationsfiler. Det här är en bra tid att granska hur anslutningsautentisering ska hanteras i produktion.
Utför 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 ändamålet och inför en godkännandeprocess som bygger på affärsmässiga motiveringar.
Säkra koddriftsättningar
Det räcker inte att bara skydda kod. Om den används i sårbara pipelines är alla säkerhetsåtgärder 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.
Produktionsfasen
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 versionsnumrerade 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. Versionerade tillgångar kan också jämföras mot publicerade meddelanden om vanliga sårbarheter och exponeringar (CVE). Du bör använda automatisering för att göra dessa jämförelser.
Akuta korrigeringar
Designen av din automatiserade pipeline bör vara tillräckligt flexibel för att stödja både reguljära och akuta driftsättningar. Den här flexibiliteten är viktig för att kunna åtgärda snabba och ansvariga säkerhetskorrigeringar.
En release är vanligtvis kopplad till flera godkännandesteg. Ö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 orsaka en regression eller en bugg. Om du vill påskynda åtgärden via en nödpipeline bör du noggrant ö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 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äkerhetsstatusen inte försämras ö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.
Stöd för 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.
Relaterad information
- Hantering av programlivscykel (ALM) med Microsoft Power Platform
- Översikt över pipelines i Power Platform
- Programlivscykelhantering för Power Platform
- Solution Architect-serien: Planera hantering av programmets livscykel för Power Platform
- Använda miljövariabler i lösningar
- Du kan använda lösningskontroll för att verifiera lösningar
- Copilot Studio Säkerhet och styrning
Checklista för säkerhet
Se den fullständiga uppsättningen med rekommendationer.