Opprette en miljøstrategi

Power Platform-miljøer er beholdere som administratorer kan bruke til å administrere apper, flyter, tilkoblinger og andre ressurser, sammen med tillatelser for å la organisasjonsmedlemmer bruke ressursene. Denne artikkelen veileder deg gjennom viktige detaljer om miljøer i Microsoft Power Platform og drøfter anbefalte metoder for å dra nytte av å administrere dem på en proaktiv måte. Mer informasjon: Oversikt over miljøer i Microsoft Power Platform

Utvikling av en miljøstrategi betyr å konfigurere miljøer og andre lag med datasikkerhet på en måte som støtter produktivitetsutvikling i organisasjonen, under sikring og ordning av ressurser. En strategi for å administrere miljøklargjøring og -tilgang og kontroll av ressurser i dem, er viktig for:

• Sikre data og tilgang.
• Forstå hvordan du bruker standardmiljøet på riktig måte.
• Administrer det riktige antallet miljøer for å unngå spredning og spare kapasitet.
• Støtte administrasjon av programlivssyklus (ALM).
• Organiser ressurser i logiske partisjoner.
• Kundestøtteoperasjoner (og brukerstøtte) for å identifisere apper som er i produksjon ved å ha dem i dedikerte miljøer.
• Kontroller at data blir lagret og overført i akseptable geografiske områder (for hensyn til ytelse og overensstemmelse).
• Sikre at programmer som utvikles, isoleres.

Forstå miljøer

Før vi kommer i gang, skal vi se på noen nøkkelfakta for miljø og sikkerhet:

• Miljøer er knyttet til en geografisk plassering som er konfigurert på det tidspunktet miljøet opprettes.
• Miljøer kan brukes til å målrette mot forskjellige målgrupper, eller til ulike formål, for eksempel utvikling, test og produksjon.
• Policyer for hindring av tap av data (DLP) kan brukes for individuelle miljøer eller leier.
• Hver leier har et standardmiljø.
• Ikke-standardmiljøer kan opprettes av lisensierte Power Apps, Power Automate og Dynamics 365-brukere. Oppretting kan begrenses til bare globale administratorer og tjenesteadministratorer via en leierinnstilling.
• Miljøer som ikke er standard, gir mer kontroll rundt tillatelser.
• Et miljø kan ha én eller flere Microsoft Dataverse-forekomster.
• Miljøer omfatter forhåndsdefinerte sikkerhetsroller som gjenspeiler vanlige kundeoppgaver med tilgangsnivåer definert slik at de passer målet med å gi tilgang til minimumsmengden av forretningsdata som kreves for å bruke appen.
• Ruting av standardmiljø er en premium-funksjon for styring. Denne funksjonen gjør at Power Platform-administratorer automatisk kan henvise nye utviklere til deres egne, personlige utviklermiljøer når de går til make.powerapps.com for første gang.

Miljøtyper

Før du begynner å utvikle en miljøstrategi, må du sørge for at du forstår de forskjellige miljøtypene.

Utvikle en strategi

Her er et utgangspunkt som kan vurderes for din miljøstrategi.

• Tilordne administratorene rollen Microsoft Power Platform-tjenesteadministrator eller Dynamics 365-tjenesteadministrator.
  Disse rollene gir administrativ tilgang til Power Apps-lerretsapper, flyter, modelldrevne apper, miljøer, egendefinerte koblinger, tilkoblinger, gatewayer, Power Apps-portaler, AI Builder-modeller og alle Dataverse-forekomster. Denne rollen bør tilordnes til administratorer som ikke trenger globale leieradministratortilgang, og som er dedikert til administrasjon av Microsoft Power Platform.

• Begrens opprettingen av nye produksjonsmiljøer til administratorer.
  Begrensning av miljøoppretting er nyttig for å opprettholde generell kontroll: både for å hindre ikke-beregnet kapasitetsforbruk og for å redusere antall miljøer som skal administreres. Hvis brukere må be om miljøer fra sentral IT, er det enklere å se hva brukerne arbeider med hvis administrator er gatekeeper.

• Behandle standardmiljøet som et bruker- og teamproduktivitetsmiljø for forretningsgruppene.
  Å gi nytt navn til miljøet ved hjelp av administrasjonssenteret, anbefales for å gjøre formålet med det aktuelle miljøet selvforklarende. Kommuniser tydelig at standard brukes for bruker- og teamproduktivitetsscenarioer, men ikke forretningsviktige eller driftskritiske apper. Dette miljøet kan ikke deaktiveres eller slettes fordi det er vert for integrasjon med produkter som SharePoint og Project. Vi anbefaler en lagdelt tilnærming til bruker- og teamproduktivitetsmiljøer.

• Opprett en prosess for å be om tilgang til eller oppretting av miljøer.
  Når opprettelse av miljø er låst og standard er reservert for førsteparts integrasjonsapper, gjør du det klart for organisasjonen din at et riktig utviklingsprosjekt bør startes ved å be om et nytt dedikert miljø der det er klar kommunikasjon av formål og støtte mellom utviklere og administratorer. Neste del har flere detaljer om automatisk oppretting av miljø, noe som bare er én måte å implementere en enkel formell forespørsels prosess på.

• Utviklings-/test-/produksjonsmiljøer for bestemte forretningsgrupper eller programmer.
  Klargjorte miljøer sikrer at endringer under utvikling ikke bryter brukerne i produksjon, og at data blir ikke skadet. Når ressurser er begrenset, fokuserer dette mønsteret på driftskritiske og viktige apper, eller på forretningsenheter som har størst behov for sitt eget, dedikerte område.

• Miljøer for individuell bruk for konseptgodkjenning og opplæring i arbeidsgrupper.
  For å være vert for seminarer, programmeringsfester og interne opplæringshendelser, for eksempel App på en dag eller Flyt på en dag, oppretter du et nytt, separat miljø for arrangementet for å holde orden på alle. Be brukerne om å lagre ressursene de trenger, i en kort periode etter arrangementet og rydde opp i miljøet, eller tilbakestille det for andre arrangementer. Bruk prøvemiljøer som ikke bruker kapasitet for disse aktivitetstypene.

• Opprette policyer for hindring av tap av data (DLP) på leietaker- og miljønivå
  Policyer for hindring av tap av data (DLP) fungerer som beskyttelsessperrer for å forhindre brukere fra å utilsiktet eksponere organisasjonsdata og for å beskytte informasjonssikkerheten i leieren. En viktig del av Power Platform-administratorrollen er å opprette og vedlikeholde DLP-policyer på leietaker- og miljønivå.

Lagdelt tilnærming til team- og brukerproduktivitetsmiljøer

Hvis du vil ha støtte for integreringer, reduserer du antall miljøer som kreves, og akselererer pålasting. Vi anbefaler at du oppretter flere delte miljøer som kan brukes av enkeltpersoner og grupper.

Standardmiljø

Alle i leieren har tillatelser til å opprette apper og flyter her. Det finnes for øyeblikket ingen måte å blokkere rolletildelingen for miljøoppretter i dette miljøet. Dette er også miljøet som brukes for førstespartsintegreringer, som opprettelse av en app fra en SharePoint-liste. Finn ut mer: Standardmiljøet

For å redusere risikoen for data bør typene koblinger som brukes i appene og flytene, begrenses til en SDL-policy som tillater mindre. Denne policyen skal dekke vanlige brukstilfeller for enkeltpersoner og små team, for eksempel arbeid med SharePoint-data, sending av e-post og å ha en arbeidsflyt for godkjenning.

Miljø for privilegert bruk

Selv om standardmiljøet dekker mange brukstilfeller, vil noen privilegerte brukere ha mer avanserte behov for appene og flytene, for eksempel integrasjon med Microsoft Teams, Microsoft Entra ID eller Azure DevOps.

For dette formålet anbefaler vi at du oppretter et miljø for privilegert bruk. Dette delte miljøet må bruke flere tillatte policyer for hindring av datatap, og administratorer må kontrollere utviklerlisten til dette miljøet.

Noen hensyn for miljøet for privilegert bruk:

• Se gjennom de tilgjengelige koblingene i dette miljøet for å forsikre deg om at det passer for brukerne dine.
• Dokumenter formålet og tilgjengelige koblinger i dette miljøet, på en klar måte, for eksempel på et SharePoint-område eller en wiki.
• Opprett en automatisk prosess for å la utviklere be om å få tilgang til miljøet for privilegert bruk, for eksempel ved hjelp av Microsoft Forms, et SharePoint-område eller en app. Hvis det er nødvendig, kan denne prosessen inkludere godkjenning av linjeleder eller IT-leder.

Egendefinerte miljøer

Selv om de delte miljøene dekker mange brukstilfeller for programmer, kan det hende at grupper og prosjekter kan dra nytte av å ha et egendefinert miljø for å støtte sine forretningsenhetsspesifikke brukstilfeller eller scenarioer for administrasjon av programlivssyklus.

Noen hensyn for egendefinerte miljøer:

• Arbeid med prosjektteamene eller forretningsenhetene for å fastsette om de krever dedikerte utviklings-, test- og produksjonsmiljøer, eller om et dedikert utviklingsmiljø og delte test- og produksjonsmiljøer passer bedre for brukstilfellet.
• Vurder dedikerte miljøer for kritiske prosjekter og arbeidsbelastninger. Utviklere har Miljøoppretter-tilgang i utviklingsmiljøet, men bare brukertilgang i test- og produksjonsmiljøet. Sluttbrukere har bare sluttbrukertilgang til produksjonsløsningen, så ingen kan endre produksjonsprogrammene.
• Vurder å dele test- og produksjonsmiljøer mellom viktige, men middels komplekse apper. Individuelle prosjekter og forretningsenheter har sitt eget utviklingsmiljø for å beskytte data, men løsninger distribueres til delte test- og produksjonsmiljøer. Utviklere er sluttbrukere i testmiljøet, og sluttbrukere har bare grunnleggende brukertilgang til løsninger og data i produksjonsmiljøet.
• Arbeid med forretningsenheten for å fastsette hvilke koblinger som kreves, og opprett en unntakspolicy.
• Samarbeid med forretningsenheten for å opprette hvem som skal være en produsent i dette miljøet, og hvem som skal være miljøadministrator.
• Hvert miljø bruker 1 GB datakapasitet, så du bør administrere egendefinerte miljøer på en fornuftig måte.

I tillegg til anbefalingene ovenfor vil oppretting av miljøstrategien også forme og dirigere DLP-strategien.

• Alle er en produsent. Meddel til alle at Standard ikke er til utvikling av kritiske apper.
• Bare én bruker har tilgang. Utvikler-miljøer er helt låst for alle andre brukere, bortsett fra brukeren som abonnerer på gruppeplanen. Programmer kan flyttes ut av miljøet hvis det er nødvendig.
• Godkjente brukere har tilgang. Delte miljøer for produktivitetsscenarioer for brukere og team, med en liste over godkjente utviklere.
• Dedikerte miljøer for kritiske prosjekter og arbeidsbelastninger. Utviklere har miljøopprettertilgang i utviklingsmiljøet, men bare brukertilgang i test- og produksjonsmiljøet. Sluttbrukere har bare sluttbrukertilgang til produksjonsløsningen, så ingen kan endre produksjonsprogrammene.
• Delte test- og produksjonsmiljøer for viktige, men middels komplekse apper. Individuelle prosjekter og forretningsenheter har sitt eget utviklingsmiljø for å beskytte data, men løsninger distribueres til delte test- og produksjonsmiljøer. Utviklere er sluttbrukere i testmiljøet, og sluttbrukere har bare grunnleggende brukertilgang til løsninger og data i produksjonsmiljøet.

Flere anbefalinger for å administrere miljøer

Her en liste over flere anbefalinger som kan gjøre det lettere å behandle miljøer, basert på vellykket opplevelse med kundeengasjementer.

• Bruk en tjenestekonto til å distribuere produksjonsløsninger: Opprett en tjenestekonto som sentral IT administrerer, for å distribuere til test- og produksjonsmiljøer. Dette er nyttig av mange årsaker:

  • Tillater at alle medlemmer av IT å administrere administratorressurser (for eksempel test- og produksjonsmiljøer).
  • Bare tjenestekontoen har administratortillatelser i miljøet.
  • Alle andre brukere har rettigheter for sluttbruker og kan ikke opprette nye ressurser – dette er viktig fordi hvis brukere får tilgang til en datatilkobling, kan de opprette et nytt grensesnitt for å samhandle med dataene som ikke var beregnet av utvikleren.
  • IT er klar over produksjonsklasse-programmer som er under distribusjon, siden de er involvert i implementeringen.
  • Tjenestekontoer må ha Microsoft Power Platform-tillatelsen eller tillatelsen tjenesteadministrator for Dynamics 365 i PIM. Tilordne flere lisenser etter behov, avhengig av hvilke koblinger som må brukes i forespørselsprosessen (for eksempel hvis Dataverse og Outlook brukes, tilordner du Premium Power Apps og Office Enterprise).
  • Når du viser detaljene for et program, viser programmet tjenestekontoen som utvikleren og ikke produsenten. Dette vil hjelpe brukere med å vite hvem som skal kontaktes hvis det oppstår programproblemer.

  Vurder om risikoen ved å ha en tjenestekonto er viktig for deg. Noen organisasjoner er ikke komfortable med å ha en tjenestekonto fordi en delt ressurs med administratorrettigheter ikke kan spores til én enkelt person. Dette er gyldig, men kan begrenses ved hjelp av trinn som å håndheve stedsbasert betinget tilgang, spore revisjonsloggene til en IP, eller flere omfattende metoder som å opprettholde en sikker arbeidsstasjon som krever bruker-ID under bruk og begrense tjenestekontoens tilgang til enheten.

• Redusere antall delte utviklingsmiljøer

  Ha separate miljøer for separat prosjektutvikling, spesielt når du behandler sikre data. Miljøer er beholdere for ressurser, for eksempel tilkoblinger til data, og i utviklingsmiljøer kan det være flere personer med miljøopprettertilgang. Hvis utvikere har tilgang til en delt datatilkobling og kan opprette apper og flyter, er det en risiko for at noen oppretter et nytt grensesnitt for å lese, oppdatere og slette data de kan ha fått tilgang til. Dette er spesielt viktig for å være oppmerksom på for standardmiljøet – du bør alltid ha viktige datatilkoblinger, egendefinerte koblinger og andre aktiva som krever sikkerhet i isolerte miljøer for å beskytte dem.

• Dele ressurser med Microsoft Entra-sikkerhetsgrupper

  Sikkerhetsgrupper kan brukes til å administrere tilgang til Power Apps, flyter, Dataverse-sikkerhetsroller og andre Office 365-tjenester, for eksempel SharePoint Online. Dette fjerner administrators ansvar for å oppdatere tilgang til individuelle sluttbrukere for hver komponent (særlig hvis flere er involvert) – appeierne kan endre dette på sikkerhetsgruppenivået uten IT (med mindre IT begrenser tilgang til administrasjon av sikkerhetsgrupper).

• Automatisere oppretting av miljø

  Administratorkoblingene (Microsoft Power Platform for Admins) gjør det mulig å opprette en godkjenningsflyt der brukere ber om miljøer når IT har begrenset opprettelse av miljø til adminintratorer. Sentral IT kan gå gjennom en forespørsel og godkjenne eller avvise opprettingen av miljøet uten at å være ansvarlig for manuelt å gå til administrasjonssenteret og opprette miljøet for brukeren, bare for å validere forespørselsdetaljene, forretningsbegrunnelsen, DLP-krav og om det er nok tilgjengelig kapasitet.

• Opprette midlertidige utviklingsmiljøer

  Som nevnt, anbefales det å atskille utviklingsmiljøer så mye som mulig, og spesielt unngå samtidig apputvikling for kritiske løsninger i standardmiljøet. Hvis miljøer opprettes for utviklingsformål, må du sette en tidsfrist for hvor lenge miljøet skal være tilgjengelig for utviklerne, og ha en prosess på plass for å sikkerhetskopiere og fjerne dem.

• Mindre er bedre

  Selv om det er viktig å sørge for at ressurser er svært rimelig fordel mellom prosjekter og forretningsenheter ved hjelp av miljøer, er det fremdeles viktig å finne en god balanse mellom sikkerhet og gjennomførbarhet. Administrasjon av delte test- og produksjonsmiljøer er en god måte å støtte et større antall viktige løsninger på, samtidig som du opprettholder kapasiteten og følger de beste fremgangsmåtene. Dette opprettholder begrensede tillatelser fordi test og produksjon har begrensede miljøtillatelser, og derfor kan ikke sluttbrukerne endre programmene.

• Klargjøre miljøer med Dataverse-forekomster i det aktuelle området

  I selskaper der ansatte arbeider i flere land/områder, kan det være noen overholdelsesbetraktninger om hvor data lagres og sendes mellom land/områder. Hvis miljøet har en Dataverse-forekomst, lagres dataene fysisk i området. Gå gjennom listen over miljøområder som støttes.

Faktorer som påvirker klargjøring

Noen faktorer påvirker når du skal klargjøre hvilke typer miljøer:

• Definerte lag av programstøtte

  Vanskelighetsgraden, hvor kritisk appen er, og brukere som påvirkes av programmet (for eksempel månedlige aktive brukere/totalt antall brukere i en org.) er alle viktige tiltak for å klargjøre miljøer for å støtte alle scenarioene.

  Forskjellige typer programmer bør atskilles i forskjellige miljøer basert på hvor viktig hvert er.

  	Driftskritiske scenarioer og/eller bruk av stor kompleksitet og/eller bruk på organisasjonsnivå. Støtte eid av IT. Solid ALM-prosess (utvikling/test/produksjon). Lengre utviklingssyklus, ofte større enn 3 måneder til det laveste produktet som er aktuelt.
  	Viktig, ikke kritisk og/eller middels komplisert og/eller tilknyttet forretningsenhet. Støtte som eies av app-eieren eller forretningsenheten, godkjent av IT. Miljøer som bruker ALM, anbefales, men er kanskje ikke nødvendige. Utvikling tar vanligvis mindre enn tre måneder til det laveste produktet som er aktuelt.
  	Produktivitetsapp som ikke trenger høyt styringsnivå. Støtte fra apputviklere. Vanligvis er ikke administrasjon av programlivssyklus nødvendig. Mindre enn to uker til det minste mulige produktet.

• Kapasitet

  Hvert miljø (i tillegg til prøve- og utviklingsmiljøer) forbruker 1 GB til å klargjøre for første gang. Dette kan være en begrensning for klargjøringsmiljøer hvis organisasjonen ikke betaler for Premium Power Apps- eller Dynamics 365-lisenser, og det også er en delt kapasitet på tvers av leieren som må tildeles til dem som trenger den.

  Spar kapasitet ved å:

  • Administrere delte test- og produksjonsmiljøer. I motsetning til delte utviklingsmiljøer bør tillatelser i test- og produksjonsmiljøer begrenses til sluttbrukertilgang for testing.
  • Automatisere rydding av midlertidige utviklingsmiljøer og oppmuntre til bruk av prøvemiljøer for testing eller konseptgodkjenningsarbeid.

• Administratorinnblanding

  Det er ikke alltid mulig å ha sentral IT involvert i alle utviklingsprosjekter i hele leieren, spesielt hvis IT-teamet er mindre, eller det er stor bedrift å administrere.

  Reduser belastningen på administratoren ved å gjøre følgende:

  • Automatisere oppretting av miljø, slik at leieradministrator bare må godkjenne forespørselen.
  • Automatisere opprydding av utviklingsmiljø med midlertidige miljøer.

Kommuniser tydelig organisasjonens miljøstrategi til utviklere

Opprett et SharePoint-område eller en wiki som klart kommuniserer:

• Formålet med standardmiljøet ditt.
• Hensikten med delte produktivitetsmiljøer for team og bruker, i tillegg til andre delte miljøer utviklere kan ha tilgang til (for eksempel opplæringsmiljøer) og prosessen for å be om tilgang til disse miljøene.
• Formålet med prøvemiljøer og hvordan de kan forespørres.
• Formålet med utviklermiljøer og hvordan de opprettes
• Prosessen med å be om egendefinerte miljøer for bestemte forretningsenhets- eller prosjektformål.
• Ansvarsområdene til en produsent:
  • Hold leieren ryddig. Slett miljøer, apper og flyter hvis de ikke lenger er nødvendige. Bruk testmiljøer hvis du eksperimenterer.
  • Del på en fornuftig måte. Unngå overdeling av miljøer, apper, flyter og delte tilkoblinger.
  • Beskytt organisasjonsdata. Unngå å flytte data fra svært konfidensielle eller konfidensielle datakilder til ikke-beskyttet eller ekstern lagring.

Kommuniser organisasjonens DLP-policyer tydelig til produsenter.