Del via

Anbefalinger til sikring af livscyklussen for udviklingen

  • Artikel

Gælder for denne Power Platform anbefaling af Well-Architected Security-tjekliste:

SE:02 Opnå en sikker livscyklus for udvikling ved hjælp af en forhærdet softwaretilførsel, som overvejende er automatiseret og kan overvåges. Indarbejd et sikkert design ved hjælp af trusselsmodeller for at beskytte mod implementeringer, der ødelægger sikkerheden.

I denne vejledning beskrives anbefalingerne til sikring af kode- og udviklingsmiljøet ved at anvende bedste sikkerhedspraksis i hele udviklingscyklussen.

Kernen i en arbejdsbelastning er de komponenter, der implementerer forretningslogikken. Disse komponenter kan være en blanding af lavkodeelementer som apps og flow på lærred og kode-første elementer som plug-ins. Alle komponenter, der udgør din arbejdsbelastning, skal være fri for sikkerhedsforanstaltninger for at sikre fortrolighed, integritet og tilgængelighed.

Det er vigtigt at sikre infrastrukturen med identitets- og netværkskontrolelementer, men det er ikke nok. Undgå implementering af Power Platform-arbejdsbelastninger og kompromitterede aktiviteter i disse arbejdsbelastninger for at styrke din overordnede sikkerhedsstilling. Processen til integration af sikkerhed i livscyklussen for din udvikling består i en hærdningsproces. På samme måde som ressourcehærdning er det også kontekst-agnostisk at opbygge kodeudvikling. Fokus er på at øge sikkerheden og ikke på programmets funktionskrav.

Definitioner

Begreb Definition
Livscyklus for sikkerhedsudvikling (SDL) Et sæt fremgangsmåder, der leveres af Microsoft , der understøtter sikkerhedssikring og overholdelseskrav.
Livscyklus for sikkerhedsudvikling (SDLC) En systematisk proces i flere trin til udvikling af softwaresystemer.

Vigtigste designstrategier

Sikkerhedsforanstaltninger skal integreres flere steder i din eksisterende SDLC (Software Development Lifecycle) for at sikre følgende:

  • Designvalg fører ikke til sikkerhedsmæssige valgmuligheder.
  • Komponenter med lav kode og første kode samt konfiguration skaber ikke sårbarheder på grund af en implementering, der kan udnyttes, og metoder til anvendelse af kode, der kan udnyttes.
  • Komponenter med lav kode og første kode og installationsprocesser brydes ikke sammen.
  • Sårbarheder, der er sårbare over for hændelser, afhjælpes.
  • Overholdelseskrav svækkes eller reduceres ikke.
  • Logføring af overvågning implementeres i alle miljøer.

Følgende afsnit indeholder sikkerhedsstrategier for de mest almindelige faser i SDLC.

Krav til fase

Målet med kravsfasen er at indsamle og analysere de funktionsrelaterede og ikke-administrative krav til en arbejdsbelastning eller en ny funktion i en arbejdsbelastning. Denne fase er vigtig, da den gør det lettere at oprette løsninger, der er skræddersyet til målene for arbejdsbelastningen. Beskyttelse af data og integriteten af din arbejdsbelastning skal være et kernekrav i alle faser af livscyklussen for udviklingen.

Overvej f.eks. en arbejdsbelastning, hvor brugere skal angive og redigere data i et program. Valgmulighederne for sikkerhedsdesign skal dække sikkerhed for brugerens interaktion med dataene, f.eks. godkendelse og godkendelse af brugeridentiteten og kun tilladte handlinger på dataene. Ikke-tekniske krav dækker tilgængelighed, anvendelighed og vedligeholdelsesmuligheder. Sikkerhedsvalgene skal omfatte opdelingsgrænser, firewall-indgående data og -udgående data samt andre sikkerhedsindstillinger, der kan afgrænses på tværs.

Alle disse beslutninger skal føre til en god definition af arbejdsbelastningens sikkerhedsmæssige stilling. Dokumentere sikkerhedskravene i en aftalt specifikation og afspejle dem i efterkravet. I dokumentet skal det eksplicit angives, hvilke sikkerhedsrisici og afvejninger og risici virksomheden vil tage på sig, hvis virksomheden ikke godkendes af interessenter i virksomheden. Du kan f.eks. dokumentere, at det er nødvendigt at bruge en IP-firewall i Power Platform-miljøer for at beskytte virksomhedens data ved kun at have Dataverse-adgang til tilladte IP-placeringer. Hvis virksomhedsinteressenter ikke vil betale de ekstra omkostninger ved at bruge en løsning som Administrerede miljøer, skal de være klar til at acceptere risikoen for, at der åbnes organisationsressourcer fra offentlige placeringer, f.eks. en kaffebar. Forestil dig også, at programmet skal oprette forbindelse til en tredjeparts datakilde. Power Platform kan have en standard-connector til dette, men den understøtter måske ikke de godkendelseskrav, der er godkendt af sikkerhedsteamene. I dette tilfælde vil dine sikkerheds interessenter muligvis acceptere risikoen ved at bruge en ikke-godkendt godkendelsesmetode. Du kan også udforske det ved hjælp af en brugerdefineret tilslutning, mens du udnytter fordelene ved øget udviklingstid og potentiel projektforskydning.

Indsamling af sikkerhedskrav er en vigtig del af denne fase. Uden denne indsats vil design- og implementeringsfaserne være baseret på ikke-udformede valg, som kan medføre ændrede sikkerhedskrav eller ændrede krav, der øger udviklingstiden. Det kan være nødvendigt at ændre implementeringen senere for at tage højde for sikkerhed.

Designfase

I denne fase konverteres sikkerhedskravene til tekniske krav. I din tekniske specifikation skal du dokumentere alle designbeslutninger for at forhindre flertydighed under implementeringen. Her er nogle typiske overvejelser:

  • Definer sikkerhedsdimensionen i arkitekturen. Overarkitekturen med sikkerhedskontrolelementer. Det kan f.eks. være kontrolelementer, der er praktiske i forbindelse med netværkets isolationsgrænser, de typer identiteter og godkendelsesmetoder, der skal bruges til komponenterne i arbejdsbelastningen, og den type krypteringsmetoder, der skal bruges.

  • Evaluer muligheder, der er leveret på platform. Det er vigtigt at forstå ansvarsfordelingen mellem dig og Power Platform. Undgå overlapning eller duplikering med indbyggede Power Platform-sikkerhedskontrolelementer. Du får bedre sikkerhedsdækning, og du kan omfordele udviklingsressourcer til programmets behov.

    I stedet for at oprette brugerdefineret logik, der reaktivt identificerer og beskeder om ikke-godkendte brugsmønstre i apps og flow, kan du f.eks. bruge politikker til forhindring af datatab til at kategorisere, hvordan forbindelser kan bruges.

    Vælg kun referenceimplementeringer, skabeloner, kodekomponenter, scripts og biblioteker, der er tillid til. Designet skal også angive et sikkert versionskontrolelement. Programafhængigheder skal komme fra parter, der er tillid til. Tredjepartsleverandører skal være i stand til at opfylde dine sikkerhedskrav og dele deres ansvarlige oplysningsplan. Eventuelle sikkerhedshændelser skal rapporteres omgående, så du kan udføre de nødvendige handlinger. Visse biblioteker eller implementeringer af referencer kan også være forbudt af organisationen. Selvom den f.eks. er sikker og fri for sårbarheder, kan den stadig være ukvalificeret, fordi den bruger funktioner, der endnu ikke er godkendt af din organisation, licensbegrænsninger eller supportmodellen for referenceimplementeringen.

    Du kan sikre, at denne vejledning følges, ved at vedligeholde en liste over godkendte og/eller ikke-godkendte rammer, biblioteker og leverandører og sikre, at dine beslutningstagere er fortrolig med denne liste. Hvis det er muligt, skal du placere dem i udviklings-pipelines for at understøtte listen. Du kan så vidt muligt automatisere brugen af værktøjer til at scanne afhængigheder for sårbarheder.

  • Gem program hemmeligheder sikkert. Implementer brugen af programhemmeligheder og forud delte nøgler, som anvendes i programmet. Legitimationsoplysninger og programhemmeligheder bør aldrig gemmes i kildekoden for arbejdsbelastningen (app eller flow). Brug eksterne ressourcer som Azure Key Vault til at sikre, at der ikke kan opnås yderligere adgang, hvis kildekoden bliver tilgængelig for en potentiel hacker.

  • Opret sikker forbindelse til dine data. Brug de stærke sikkerhedsfunktioner, hvor Microsoft Dataverse tilbyder at beskytte dine data, f.eks. rollebaseret sikkerhed og sikkerhed på kolonneniveau. I forbindelse med andre datakilder skal du bruge forbindelser, der har sikre godkendelsesmetoder. Undgå forespørgsler, hvor brugernavn og adgangskode lagres som almindelig tekst. Undgå HTTP til oprettelse af brugerdefinerede connectors.

  • Definer, hvordan slutbrugerne interagerer med arbejdsbelastningen og data. Overvej, om brugerne har direkte adgang til dataene, hvilket adgangsniveau de har brug for, og hvorfra de har adgang til dataene. Tænk over, hvordan programmer deles med slutbrugere. Sørg for, at det kun er de personer, der skal have adgang til appen og dataene, der har adgang. Undgå komplekse sikkerhedsmodeller, der opfordrer til løsninger for at undgå sikkerhedsblokke.

  • Undgå hård kodning. Undgå hård kodning af URL-adresser og nøgler. Du kan f.eks. undgå hård kodning i en Power Automate HTTP-handling, hvis webadressen eller nøglen til backend-tjenesten. Brug i stedet en brugerdefineret connector eller brug en miljøvariabel til URL-adressen og Azure Key Vault til API-nøglen.

  • Definer testplaner. Definer tydelige testsager for sikkerhedskrav. Vurdere, om du kan automatisere disse test i dine pipelines. Hvis teamet har processer til manuel test, skal du inkludere sikkerhedskrav til disse test.

Bemærk

Udfør trusselsmodeller i denne fase. Trusselsmodeller kan bekræfte, at designvalg er tilpasset sikkerhedskravene og viser, hvad du skal afhjælpe. Hvis din arbejdsbelastning håndterer meget følsomme data, skal du være sikkerhedseksperter, der kan hjælpe dig med at udføre trusselsmodellering.

Den første opgave med trusselsmodeller bør forekomme i designfasen, når softwarens arkitektur og design på højt niveau defineres. Når du gør det i denne fase, kan du nemmere identificere potentielle sikkerhedsproblemer, før de indgår i systemets struktur. Denne opgave er dog ikke en engangsaktivitet. Det er en løbende proces, der skal fortsætte i hele softwarens verden.

Du kan finde flere oplysninger i Anbefalinger af trusselsanalyse.

Udvikling og testfase

I denne fase er målet at forhindre sikkerhedsdefekter og manipulere kode-, build- og installationspipelines.

Vær veltrænet i sikre kodemetoder

Udviklingsteamet skal have oplæring i sikre kodningsmetoder. Udviklere skal f.eks. kende sikkerhedskoncepterne i Microsoft Dataverse til at implementere en sikkerhedsmodel med mindst rettigheder, sikkerhedspolitikker for indhold for modelbaserede apps for at begrænse indlejring til domæner, der er tillid til, og connector-/on-premise gateway-godkendelsesmetoder.

Udviklere skal fuldføre denne oplæring, før de begynder at arbejde med arbejdsbelastninger i Power Platform.

Foretag interne peer code-gennemgange for at øge den løbende læring.

Brug værktøjer til kodeanalyse

Løsningskontrol skal bruges til Power Platform-ressourcer, og kildekoden til enhver traditionel kode kan kontrolleres for potentielle sikkerhedsfejl, herunder tilstedeværelse af legitimationsoplysninger i kode. Identificer mulige forekomster af legitimationsoplysninger og hemmelig godkendelse i kildekode- og konfigurationsfiler. Det er et godt tidspunkt til at gennemgå, hvordan forbindelseslegitimationsoplysninger håndteres i produktionen.

Udføre logiktest

Brug forkert udformede og uventede data til at kontrollere sikkerhedsrisici og validere fejlbehandling, især vigtigt med løsninger, der omfatter Power Pages.

Skriv lige nok kode

Når du reducerer mængden af kode, reducerer du også risikoen for sikkerhedsbelastning. Genbrug kode og biblioteker, der allerede er i brug og har været igennem sikkerhedsvalideringer i stedet for at duplikere kode. Registrering af åben software og kontrol af version, sårbarhed og juridiske forpligtelser. Der er en voksende mængde open source-ressourcer i Power Platform, så det skal ikke overses. Hvis det er muligt, bør dette gennemgås i designfasen for at undgå problemer i sidste øjeblik.

Beskyt udviklermiljøer

Developer-arbejdsstationer skal beskyttes med stærke netværks- og identitetskontrolelementer for at forhindre, at brugerne bliver det. Kontrollér, at sikkerhedsopdateringer anvendes korrekt.

Kildekodelageret skal også beskyttes . Giv adgang til kodelagre på need-to-know-basis, og reducer sårbarheder så meget som muligt for at undgå angreb. Få en grundig proces til at gennemgå kode for sikkerhedssårbarheder. Brug sikkerhedsgrupper til dette formål, og implementer en godkendelsesproces, der er baseret på forretningsmæssige behov.

Sikre kodeinstallationer

Det er ikke nok kun at sikre kode. Hvis den kører i udnyttede pipelines, er alle sikkerhedsindsatser nyttesløse og ufuldstændige. Byg og frigiv miljøer skal også beskyttes , fordi du vil forhindre skadelige aktører i at køre skadelig kode i din pipeline.

Vedligeholde en opdateret opgørelse over alle komponenter, der er integreret i dit program

Alle nye komponenter, der er integreret i et program, øger angrebs overflade. Du kan sikre korrekt ansvar og vigtige beskeder, når nye komponenter tilføjes eller opdateres, ved at oprette en opgørelse over disse komponenter. Jævnligt skal du kontrollere, at dit manifest stemmer overens med det, der er i din buildproces. Hvis du gør det, kan du sikre, at der ikke uventet tilføjes nye komponenter, der indeholder skadelige programmer eller anden malware.

Det anbefales, at du bruger pipelines til Power Platform til dine installationer. Udvide pipelines ved hjælp af GitHub-handlinger. Hvis du bruger GitHub-arbejdsprocesser, skal du foretrække Microsoft oprettede opgaver. Du kan også validere opgaver, fordi de kører i sikkerhedskonteksten for pipelinen.

Undersøg brugen af service principper for installation.

Produktionsfase

Produktionsfasen præsenterer den sidste ansvarlige mulighed for at løse problemer med sikkerheden. Registrer den opdatering, der er udgivet i produktionen.

Bevare versionerede artefakter

Opbevare et katalog over alle installerede aktiver og deres versioner. Disse oplysninger er nyttige under en hændelsesforløb, når du afhjælper problemer, og når du får systemet tilbage til at fungere. Versionerede aktiver kan også sammenlignes med publicerede CVE-meddelelser (Common Vulnerabilities and Vulnerabilities). Du bør bruge automatisering til at foretage disse sammenligninger.

Løsning af problemer i forbindelse med udløsninger

Dit automatiserede pipelinedesign skal have den nødvendige fleksibilitet til at understøtte både almindelige og automatiserede installationer. Denne fleksibilitet er vigtig for at understøtte hurtige og ansvarlige sikkerhedsrettelser.

En version knyttes typisk til flere godkendelser. Overvej at oprette en proces til hurtig løsning af sikkerheden. Processen kan omfatte kommunikation mellem grupper. Pipelinen skal gøre det muligt at installere hurtige installationer af roll-forward og rollback, der omfatter sikkerhedsrettelser, vigtige opdateringer og kodeopdateringer, der indtræffer uden for den almindelige livscyklus for installationen.

Bemærk

Du skal altid prioritere sikkerhedsrettelser frem for nemheds skyld. En sikkerhedsrettelse skal ikke introducere en regression eller fejl. Hvis du vil fremskynde rettelsen via en pipeline til pipelinen til pipelinen, skal du nøje overveje, hvilke automatiserede test der kan omgås. Evaluere værdien af de enkelte test i forhold til eksekveringstiden. Enhedstest fuldføres f.eks. som regel hurtigt. Integrationstest eller test fra slutpunkt til slutpunkt kan køre i lang tid.

Holde forskellige miljøer adskilt

Produktionsdata skal ikke bruges i lavere miljøer**, da de pågældende miljøer måske ikke har de strenge sikkerhedskontrolelementer, som produktionen har. Undgå at oprette forbindelse fra et program, der ikke er et produktionsprogram, til en produktionsdatabase, og undgå at oprette forbindelse mellem komponenter, der ikke er produktionskomponenter, og produktionsnetværker.

Brug progressivt stigende antal

Brug progressiv berettigelse til at frigive funktioner til en delmængde af brugere baseret på valgte kriterier. Hvis der er problemer, minimeres påvirkningen til disse brugere. Denne fremgangsmåde er en almindelig strategi til begrænsning af risikoen, da den reducerer overfladeområdet. Efterhånden som funktionen modnes, og du har større tillid til sikkerhed, kan du efterhånden frigive den til et bredere sæt brugere.

Vedligeholdelse af fase

Målet med denne fase er at sikre, at sikkerhedsstillinger ikke fungerer på samme måde over tid. SDLC er en løbende, fleksibel proces. Begreber, der er omfattet af de foregående faser, gælder for denne fase, fordi kravene ændres over tid.

Løbende forbedring. Løbende vurdere og forbedre sikkerheden i softwareudviklingsprocessen ved at tage højde for kode gennemgange, feedback, indlærte erfaringer og ændrede trusler samt nye funktioner, der bliver gjort tilgængelige af Power Platform.

Nedbryd ældre aktiver , der er forældede eller ikke længere er i brug. Hvis du gør det, reduceres programmets overfladeområde.

Vedligeholdelse omfatter også løsning af hændelser. Hvis der findes problemer i produktionen, skal de straks integreres tilbage i processen, så de ikke gentager sig.

Du kan løbende forbedre dine fremgangsmåder for sikker kodning for at holde dig i overensstemmelse med trusselsbilledet.

SDL i Microsoft Power Platform

Power Platform er baseret på en kultur og metode til sikkert design. Både kultur og metodologi styrkes konstant gennem Microsoft branchens brancheførende Security Development Lifecycle (SDL) og Threat Modeling-praksisser .

Den robuste proces til gennemgang af trusselsmodeller sikrer, at trusler identificeres i designfasen, afhjælpes og valideres for at sikre, at de er blevet afhjulpet.

Trusselsmodellering står også for alle ændringer af tjenester, der allerede er aktive gennem løbende jævnlige gennemgange. Hvis du bruger STRIDE-modellen, kan du løse de mest almindelige problemer med usikkert design.

Microsoft's SDL svarer til OWASP Software Assurance Maturity Model (SAMM). Begge er baseret på den forudsætning, at et sikkert design er en integreret del af sikkerheden i webprogrammet. Du kan finde flere oplysninger i OWASP Top 10 Risici: Afhjælpninger i Power Platform.

Power Platform-processtyring

Microsoft SDL (Security Development Lifecycle) anbefaler sikre fremgangsmåder, som du kan anvende på din udviklingslivscyklus. Du kan finde flere oplysninger under Microsoft Livscyklus for sikkerhedsudvikling.

DevOps og SAST-værktøjerne (Static Application Security Testing) er inkluderet som en del af GitHub Advanced Security og Azure DevOps. Disse værktøjer kan hjælpe dig med at spore organisationens sikkerhedspoint.

Med løsningskontrolfunktionen kan du udføre et omfattende statisk analysetjek af dine løsninger i forhold til et sæt af regler for bedste praksis og hurtigt identificere de problematiske mønstre. Se Brug løsningskontrollen til at validere din løsning.

Kontrolliste til sikkerhed

Se det fuldstændige sæt anbefalinger.

Tjekliste for sikkerhed