Del via

Anbefalinger for sikring av en utviklingssyklus

  • Artikkel

Gjelder for denne Power Platform anbefalingen for sjekkliste for godt strukturert sikkerhet:

SE:02 Oppretthold en sikker utviklingssyklus ved å bruke en forsterket, for det meste automatisert programvareforsyningskjede som kan overvåkes. Bruk en sikker utforming ved hjelp av trusselmodellering for å beskytte mot implementeringer som omgår sikkerheten.

Denne veiledningen beskriver anbefalingene for sikring av kode- og utviklingsmiljøet ved å bruke anbefalte fremgangsmåter for sikkerhet gjennom hele utviklingssyklusen.

Kjernen i en arbeidsbelastning er komponentene som implementerer forretningslogikken. Disse komponentene kan være en blanding av lavkodeelementer, for eksempel lerretsapper og flyter, og kode-først-elementer, for eksempel programtillegg. Alle komponenter som utgjør arbeidsbelastningen, må være fri for sikkerhetssvakheter for å sikre konfidensialitet, integritet og tilgjengelighet.

Det er viktig å sikre infrastrukturplanet med identitets- og nettverkskontroller, men dette er ikke nok. Forhindre dårlig implementering av Power Platform-arbeidsbelastninger og utsatte aktiviteter i disse arbeidsbelastningene for å øke sikkerheten generelt. Prosessen med å integrere sikkerhet i utviklingssyklusen er i høy grad en forsterkingsprosess. Strengere kontroll med kodeutvikling er også uavhengig av kontekst, akkurat som ressursforsterking. Fokuset er på å øke sikkerheten, ikke på funksjonskravene i programmet.

Definisjoner

Term Definisjon
Livssyklus for sikkerhetsutvikling (SDL) Et sett med fremgangsmåter som leveres av Microsoft som støtter sikkerhetssikring og samsvarskrav.
Livssyklus for programvareutvikling (SDLC) En systematisk prosess med flere faser for utvikling av programvaresystemer.

Viktige utformingsstrategier

Sikkerhetstiltak må integreres på flere steder i den eksisterende SDLC-en (livssyklus for programvareutvikling) for å sikre følgende:

  • Utformingsvalg fører ikke til sikkerhetsbrudd.
  • Lavkodekomponenter og kode-først-komponenter samt konfigurasjon skaper ikke sikkerhetsproblemer på grunn av implementering som kan utnyttes, og uriktig kodepraksis.
  • Lavkodekomponenter, kode-først-komponenter og utviklingsprosesser blir ikke ulovlig endret.
  • Sikkerhetsproblemer som oppdages i hendelser, løses.
  • Krav til forskriftssamsvar blir ikke utsatt for kompromiss eller reduseres.
  • Logging av sporing av endringer implementeres i alle miljøer.

Delene nedenfor inneholder sikkerhetsstrategier for de vanlige fasene i SDLC.

Kravfasen

Målet med kravfasen er å samle inn og analysere de funksjonelle og ikke-funksjonelle kravene for en arbeidsbelastning eller en ny funksjon i en arbeidsbelastning. Denne fasen er viktig fordi den legger til rette for oppretting av beskyttelsessperrer som er skreddersydd til målene med arbeidsbelastningen. Beskyttelse av dataene og integriteten til arbeidsbelastningen skal være et kjernekrav i alle faser av utviklingssyklusen.

La oss si at vi har en arbeidsbelastning der brukere skal angi og endre data i et program. Valgene i sikkerhetsutformingen skal dekke forsikringer om brukerens samhandling med dataene, for eksempel godkjenning og autorisering av brukeridentiteten, og bare la tillatte handlinger utføres på dataene. Ikke-funksjonelle krav dekker tilgjengelighet, brukervennlighet og vedlikehold. Sikkerhetsvalg skal omfatte segmenteringsgrenser, inngående og utgående brannmur, og andre sikkerhetshensyn på tvers av systemet.

Alle disse beslutningene skal føre til en god definisjon av sikkerhetsstatusen for arbeidsbelastningen. Dokumenter sikkerhetskravene i en avtalt spesifikasjon, og gjenspeil dem i gjenværende arbeid. Dokumentet skal eksplisitt oppgi sikkerhetsinvesteringene, kompromissene og risikoene som virksomheten er villig til å ta på seg, hvis investeringene ikke godkjennes av forretningsinteressenter. Du kan for eksempel dokumentere behovet for å bruke en IP-brannmur i Power Platform-miljøer til å beskytte organisasjonsdataene, ved å begrense tilgang til Dataverse for bare tillatte IP-lokasjoner. Hvis forretningsinteressenter ikke er villige til å ta på seg tilleggskostnadene ved bruk av en løsning som administrerte miljøer, må de være rede til å akseptere risikoen ved at det går an å få tilgang til organisasjonsressurser fra offentlige steder, for eksempel en kafé. La oss si i et annet eksempel at programmet må kunne koble til en datakilde fra en tredjepart. Power Platform kan ha en ferdiglaget kobling til dette, men den støtter kanskje ikke godkjenningskravene som er godkjent av sikkerhetsteamene. I dette tilfellet kan det hende at sikkerhetsinteressentene er villige til å godta risikoen ved bruk av en godkjenningsmetode som ikke er godkjent. Du kan alternativt utforske hvordan du bruker en egendefinert kobling, samtidig som du veier fordelene ved økt utviklingstid mot mulig prosjektforsinkelse.

Innsamling av sikkerhetskrav er en avgjørende del av denne fasen. Uten dette arbeidet blir utformings- og implementeringsfasene basert på uuttalte valg, som kan føre til sikkerhetsbrudd eller endrede krav som øker utviklingstiden. Du må kanskje endre implementeringen senere for å ta hensyn til sikkerhet, som kan bli dyrt.

Utformingsfasen

I løpet av denne fasen blir sikkerhetskravene konvertert til tekniske krav. Dokumenter alle utformingsbeslutninger i den tekniske dokumentasjonen for å unngå tvetydighet under implementeringen. Her er noen typiske oppgaver:

  • Definer sikkerhetsdimensjonen ved arkitekturen. Legg sikkerhetskontroller over arkitekturen. Dette kan for eksempel være kontroller som er praktiske for nettverksisolasjonsgrensene, typene identiteter og godkjenningsmetoder som kreves for komponentene i arbeidsbelastningen, og typen krypteringsmetoder som skal brukes.

  • Evaluer plattformgitte handlingsmuligheter. Det er viktig å forstå ansvarsfordelingen mellom deg og Power Platform. Unngå overlapping eller duplisering med innebygde Power Platform-sikkerhetskontroller. Dermed får du bedre sikkerhetsdekning og kan omfordele utviklingsressurser etter behovene til programmet.

    Du kan for eksempel bruke policyer for hindring av datatap til å kategorisere hvordan koblinger kan brukes, i stedet for å lage egendefinert logikk som reaktivt finner og varsler om bruksmønstre i apper og flyter som ikke er godkjent.

    Velg bare klarerte referanseimplementeringer, maler, kodekomponenter, skript og biblioteker. Utformingen skal også angi sikker versjonskontroll. Programavhengigheter skal komme fra klarerte parter. Tredjepartsleverandører skal kunne oppfylle sikkerhetskravene dine og dele sin plan for ansvarlig avsløring. Eventuelle sikkerhetshendelser skal rapporteres umiddelbart, slik at du kan utføre nødvendige handlinger. Enkelte biblioteker eller referanseimplementeringer kan også forbys av organisasjonen. Selv om de for eksempel er sikre og uten sikkerhetsproblemer, kan de likevel forbys fordi de bruker funksjoner som ennå ikke er godkjent av organisasjonen, lisensbegrensninger eller støttemodellen for referanseimplementeringene.

    For å sikre at denne veiledningen følges, vedlikeholder du en liste over godkjente og/eller ikke godkjente rammeverk, biblioteker og leverandører og sikrer at utviklerne har informasjonen i denne listen. Bruk beskyttelsessperrer i utviklingspipelinene der det er mulig, for å støtte listen. Automatiser bruken av verktøy så mye som mulig, for å se etter sikkerhetsproblemer i avhengigheter.

  • Lagre programhemmeligheter trygt. Implementer bruken av programhemmeligheter og forhåndsdelte nøkler som programmet bruker, på en sikker måte. Legitimasjon og programhemmeligheter skal aldri lagres i kildekoden for arbeidsbelastningen (appen eller flyten). Bruk eksterne ressurser, for eksempel Azure Key Vault, til å sikre at det ikke går an å få ytterligere tilgang hvis kildekoden blir tilgjengelig for en potensiell angriper.

  • Koble deg til dataene på en sikker måte. Bruk de sterke sikkerhetsfunksjonene som Microsoft Dataverse tilbyr, til å beskytte dataene, for eksempel rollebasert sikkerhet og kolonnenivåsikkerhet. Når det gjelder andre datakilder, bruker du koblinger som har sikre godkjenningsmetoder. Unngå spørringer som lagrer brukernavn og passord i ren tekst. Unngå HTTP for opprettelse av egendefinerte koblinger.

  • Definer hvordan sluttbrukere skal samhandle med arbeidsmengden og dataene. Vurder om brukere skal ha direkte tilgang til dataene, hvilket tilgangsnivå de må ha, og hvor de skal ha tilgang til dataene fra. Tenk på hvordan programmer skal deles med sluttbrukere. Kontroller at bare de som trenger tilgang til appen og dataene, har tilgang. Unngå komplekse sikkerhetsmodeller som oppfordrer til midlertidige løsninger for å unngå sikkerhetsblokkeringer.

  • Unngå hardkoding. Unngå hardkoding av nettadresser og nøkler. Unngå for eksempel hardkoding i en HTTP-handling for Power Automate, nettadressen eller nøkkelen til serverdeltjenesten. Bruk i stedet en egendefinert kobling, eller bruk en miljøvariabel for nettadressen og Azure Key Vault for API-nøkkelen.

  • Definer testplaner. Definer klare testtilfeller for sikkerhetskrav. Vurder om du kan automatisere disse testene i pipelinene. Hvis teamet har prosesser for manuell testing, tar du med sikkerhetskrav for disse testene.

Merk

Foreta trusselmodellering i denne fasen. Trusselmodellering kan bekrefte at utformingsvalgene er rettet inn etter sikkerhetskrav og eksponerer trusler du bør redusere. Hvis arbeidsbelastningen håndterer svært sensitive data, investerer du i sikkerhetseksperter som kan hjelpe deg å foreta trusselmodellering.

Den første trusselmodelleringsøvelsen skal skje i løpet av utformingsfasen når programvarens arkitektur og høynivåutforming defineres. Når du gjør dette i denne fasen, blir det enklere å identifisere potensielle sikkerhetsproblemer før de havner i systemstrukturen. Denne øvelsen er imidlertid ikke en engangsaktivitet. Det er en kontinuerlig prosess som må fortsette gjennom hele utviklingen av programvaren.

Hvis du vil ha mer informasjon, kan du se Anbefalinger for trusselanalyse.

Utviklings- og testfasen

I løpet av denne fasen er målet å forhindre sikkerhetssvakheter og ulovlige endringer i pipeliner for kode, bygg og distribusjon.

Ha god opplæring i sikker kodepraksis

Utviklingsteamet skal ha opplæring i sikker kodepraksis. Utviklere skal for eksempel ha kjennskap til sikkerhetskonsepter i Microsoft Dataverse for å implementere en sikkerhetsmodell med minimale rettigheter, policyer for innholdssikkerhet for modelldrevne apper for å begrense innebygging til klarerte domener, og koblingsbaserte/lokale godkjenningsmetoder for gateway.

Utviklere må fullføre denne opplæringen før de begynner å arbeide med Power Platform-arbeidsbelastninger.

Foreta intern fagfellevurdering av kode for å fremme kontinuerlig læring.

Bruke kodeanalyseverktøy

Løsningskontroll skal brukes til Power Platform-ressurser, og kildekode for enhver tradisjonell kode kan kontrolleres for mulige sikkerhetsfeil, inkludert legitimasjon i kode. Identifiser mulige forekomster av legitimasjon og eksponering av hemmeligheter i kildekode- og konfigurasjonsfiler. På dette tidspunktet er det gunstig å gå gjennom hvordan tilkoblingslegitimasjon blir håndtert i produksjon.

Utfør sårbarhetstesting

Bruk feil utformede og uventede data til å se etter sikkerhetsproblemer og validere feilhåndtering, som er spesielt viktig med løsninger som omfatter Power Pages.

Skriv akkurat nok kode

Når du reduserer fotavtrykket til koden, reduserer du også sjansene for sikkerhetssvakheter. Gjenbruk kode og biblioteker som allerede er i bruk og har vært gjennom sikkerhetsvalideringer i stedet for duplisering av kode. Registrering og kontroll av versjon, sikkerhetsproblemer og juridiske forpliktelser ved programvare med åpen kildekode. Det finnes en økende mengde ressurser for Power Platform med åpen kildekode, så dette bør ikke overses. Når det er mulig, bør dette diskuteres i utformingsfasen for å unngå problemer i siste liten.

Beskytt utviklingsmiljøer

Arbeidsstasjoner for utviklere må beskyttes med sterke nettverks- og identitetskontroller for å forhindre eksponering. Sørg for flittig installasjon av sikkerhetsoppdateringer.

Kildekodelageret må også beskyttes . Gi tilgang til koderepositorier bare når det er nødvendig, og reduser eksponering av sårbarheter så mye som mulig for å unngå angrep. Ha en grundig prosess for å gjennomgå kode for sikkerhetsproblemer. Bruk sikkerhetsgrupper til dette formålet, og implementer en godkjenningsprosess som er basert på forretningsbegrunnelser.

Sikre kodedistribusjoner

Det er ikke nok å sikre bare kode. Hvis den kjører i pipeliner som kan utnyttes, er alle sikkerhetstiltak forgjeves og ufullstendige. Bygg- og utgivelsesmiljøer må også beskyttes fordi du vil forhindre at skadelige aktører kjører skadelig kode i datasamlebåndet.

Oppretthold en oppdatert beholdning av hver komponent som er integrert i programmet

Alle nye komponenter som er integrert i et program, øker angrepsoverflaten. For å sikre riktig ansvarlighet og varsling når nye komponenter legges til eller oppdateres, bør du ha en beholdning med disse komponentene. Kontroller regelmessig at manifestet samsvarer med det som er i byggeprosessen. Når du gjør dette, sikrer du at ingen nye komponenter som inneholder bakdører eller annen skadelig programvare, blir uventet lagt til.

Vi anbefaler at du bruker Pipelines for Power Platform for distribusjonene. Utvid pipeliner ved hjelp av GitHub-handlinger. Hvis du bruker GitHub-arbeidsflyter, foretrekker Microsoft du forfattede oppgaver. Valider også oppgavene fordi de kjører i sikkerhetskonteksten for pipelinen.

Utforsk bruken av tjenestekontohavere for distribusjon.

Produksjonsfasen

Produksjonsfasen byr på den siste ansvarlige muligheten til å løse sikkerhetsbrudd. Registrer hovedavbildningen som gis ut i produksjon.

Behold versjonsnummererte artefakter

Hold en katalog over alle distribuerte aktiva og versjonene deres. Denne informasjonen er nyttig under hendelsesbehandling, når du reduserer problemer og får systemet tilbake til fungerende tilstand. Versjonsnummererte aktiva kan også sammenlignes med publiserte merknader om Vanlige sårbarheter og eksponeringer (CVE). Du bør bruke automatisering til å utføre disse sammenligningene.

Nødreparasjoner

Den automatiserte pipelineutformingen skal ha fleksibiliteten til å støtte både vanlige distribusjoner og nøddistribusjoner. Denne fleksibiliteten er viktig for å støtte raske og ansvarlige sikkerhetsrettelser.

En utgivelse er vanligvis knyttet til flere godkjenningsporter. Vurder å opprette en nødprosess for å akselerere sikkerhetsrettelser. Prosessen kan involvere kommunikasjon mellom team. Pipelinen skal tillate hurtige fremoverrullings- og tilbakerullingsdistribusjoner som håndterer sikkerhetsrettelser, kritiske feil og kodeoppdateringer som forekommer utenfor den vanlige distribusjonssyklusen.

Merk

Prioriter alltid sikkerhetsrettelser fremfor bekvemmelighet. En sikkerhetsrettelse skal ikke introdusere en regresjon eller feil. Hvis du vil akselerere rettelsen via en nødpipeline, må du vurdere nøye hvilke automatiske tester som kan omgås. Evaluer verdien av hver test mot kjøringstiden. Enhetstester fullføres for eksempel vanligvis raskt. Integrerings- eller ende-til-ende-tester kan kjøre i lang tid.

Holde ulike miljøer atskilt

Produksjonsdata skal ikke brukes i lavere miljøer**, fordi det er ikke sikkert at disse miljøene har de strenge sikkerhetskontrollene som produksjon har. Unngå å koble fra et ikke-produksjonsprogram til en produksjonsdatabase, og unngå å koble ikke-produksjonskomponenter til produksjonsnettverk.

Bruk progressiv eksponering

Bruk progressiv eksponering til å gi ut funksjoner til et delsett av brukere basert på valgte kriterier. Hvis det oppstår problemer, blir virkningen minimert til disse brukerne. Denne tilnærmingen er en vanlig strategi for å redusere risikoen, fordi dette reduserer overflaten. Etter hvert som funksjonen blir moden og du er mer trygg på sikkerhetsforsikringer, kan du gradvis gi en ut til et mer variert sett av brukere.

Vedlikeholdsfasen

Målet med denne fasen er å sikre at sikkerhetsstatusen ikke svekkes over tid. SDLC er en pågående smidig prosess. Konsepter som ble gjennomgått i de foregående fasene, gjelder for denne fasen siden kravene endres over tid.

Kontinuerlig forbedring. Vurder og forbedre sikkerheten for programvareutviklingsprosessen kontinuerlig ved å ta hensyn til kodegjennomganger, tilbakemelding, det du har lært av erfaring, og trusler i utvikling, i tillegg til nye funksjoner som gjøres tilgjengelige av Power Platform.

Ta eldre ressurser ut av drift som er foreldet eller ikke lenger er i bruk. Når du gjør dette, reduseres overflaten til programmet.

Vedlikehold omfatter også hendelsesrettelser. Hvis det oppstår problemer i produksjonen, må de integreres tilbake i prosessen omgående, slik at de ikke oppstår på nytt.

Forbedre den sikre kodepraksisen kontinuerlig for å følge med på trusselbildet.

SDL i Microsoft Power Platform

Power Platform er bygd på en kultur og metodikk for sikker design. Både kultur og metodikk forsterkes kontinuerlig gjennom Microsoft sin bransjeledende sikkerhetsutviklingslivssyklus (SDL) og trusselmodelleringspraksis .

Gjennomgangsprosessen for trusselmodellering sikrer identifiseres i utviklingsfasen, overføres og valideres for å sikre at de er redusert.

Trusselmodellering står også for alle endringer i tjenester som allerede vises, gjennom kontinuerlige regelmessige gjennomganger. Å være avhengig av STRIDE-modellen bidrar til å løse de vanligste problemene med usikker design.

Microsofts SDL tilsvarer OWASP Software Assurance Maturity Model (SAMM). Begge er bygd på premisset om at sikker design er integrert i nettprogramsikkerhet. Hvis du vil ha mer informasjon, kan du se OWASPs ti største risikoer: reduksjoner i Power Platform.

Tilrettelegging for Power Platform

Microsoft Security Development Lifecycle (SDL) anbefaler sikre fremgangsmåter som du kan bruke i utviklingslivssyklusen. Hvis du vil ha mer informasjon, kan du se Microsoft Livssyklus for sikkerhetsutvikling.

Verktøyene Defender for DevOps og SAST (Static Application Security Testing) er inkludert som en del av GitHub Advanced Security og Azure DevOps. Disse verktøyene kan hjelpe deg å spore en sikkerhetspoengsum for organisasjonen.

Med løsningskontrollen kan du utføre en omfattende statisk analysekontroll av løsningene mot et sett med regler for beste fremgangsmåte og raskt finne disse problematiske mønstrene. Se Bruk løsningskontroll til å validere løsningene.

Sikkerhetssjekkliste

Se hele settet med anbefalinger.

Sjekkliste for sikkerhet